On 1/15/23 12:41, pf@xxxxxxxxxxx wrote:
On Sun, 15 Jan 2023 12:23:10 -0800 Adrian Klaver wrote:
On 1/15/23 11:27, pf@xxxxxxxxxxx wrote:
Hi,
I'm fairly new to postgres; but have databases with about 2TB of data.
Trying to upgrade from 13.6 to 15.1, pg_upgrade complains with:
[postgres@pf ~]$ /usr/bin/pg_upgrade -b /usr/local/pgsql/bin -B /usr/bin \
-d /mnt/db/var/lib/pgsql/data -D /mnt/work/var/lib/pgsql/data \
-s /tmp -U postgres
Nothing I read implies the need to upgrade to 14.x first... Right?
In addition to Tom Lane's comments I would recommend reading this:
https://www.postgresql.org/docs/current/pgupgrade.html
multiple times. There is a lot going on there and it will take a couple
of reads at least to begin to understand it all.
Yup... that's what I've been working from... See my reply to Tom re
--link...
1) Working from and understanding are two different things. For instance
further on in the docs there is:
--clone
Use efficient file cloning (also known as “reflinks” on some
systems) instead of copying files to the new cluster. This can result in
near-instantaneous copying of the data files, giving the speed
advantages of -k/--link while leaving the old cluster untouched.
File cloning is only supported on some operating systems and file
systems. If it is selected but not supported, the pg_upgrade run will
error. At present, it is supported on Linux (kernel 4.5 or later) with
Btrfs and XFS (on file systems created with reflink support), and on
macOS with APFS.
2) From the docs:
Run pg_upgrade
Always run the pg_upgrade binary of the new server, not the old one.
pg_upgrade requires the specification of the old and new cluster's data
and executable (bin) directories. You can also specify user and port
values, and whether you want the data files linked or cloned instead of
the default copy behavior.
3) Again, read the docs multiple times there is a lot to understand.
Thanks!
Thanks
Pierre
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
