Thread: update to 16.2
Hello, We plan to update our customers on SuSE Linux from 11.4, 13.1, 14.1 and 15.1 to 16.2. Do I understand the release notes correct that for this the way is only dump/restore? The release notes say: https://www.postgresql.org/docs/release/16.2/ ... A dump/restore is not required for those running 16.X. ... It does not say definitely that for all other versions a dump/restore is required. We could even unload in the databases the ~400 tables to COPY format, re-create the tables in a new 16.2 server and load the ~400 files (all this relatively easy per scripts we created to migrate from Sybase and Oracle to PostgreSQL). But I think, producing the dump with the old version, setup new cluster and load the dump with the 16.2 sql command will work. Any comments? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
> On Mar 8, 2024, at 00:53, Matthias Apitz <guru@unixarea.de> wrote: > It does not say definitely that for all other versions a dump/restore is > required. You cannot just replace the binaries to upgrade from an earlier major version to 16.X. The release notes use "a dump/restore(is/is not) required" to indicated whether you can just replace the binaries ("is not") and restart the serveron the same database files. Dump/restore is not the only option for a major version upgrade. You can use the pg_upgrade utility that is part of thestandard distribution, or logical replication to a new server on the new version.
> On 8 Mar 2024, at 09:53, Matthias Apitz <guru@unixarea.de> wrote: > It does not say definitely that for all other versions a dump/restore is > required. I recommend reading https://www.postgresql.org/docs/16/upgrading.html before attempting anything. Minor version upgrades and major version upgrades are very different things. -- Daniel Gustafsson
El día viernes, marzo 08, 2024 a las 12:56:16 -0800, Christophe Pettus escribió: > > > > On Mar 8, 2024, at 00:53, Matthias Apitz <guru@unixarea.de> wrote: > > It does not say definitely that for all other versions a dump/restore is > > required. > > You cannot just replace the binaries to upgrade from an earlier major version to 16.X. The release notes use "a dump/restore(is/is not) required" to indicated whether you can just replace the binaries ("is not") and restart the serveron the same database files. > I know we can't just switch the binaries and restart the server. We're compiling the PostgreSQL software by our own (even with some small changes in the C-code) and deliver the full tree as /usr/local/sisis-pap/pgsql-11.1 /usr/local/sisis-pap/pgsql-14.1 /usr/local/sisis-pap/pgsql-15.1 ... Also the migration path for customers is described and based on pg_dumpall, setup a new cluster fromm the above new version and load the dump with the new psql command into. The other option (pg_upgrade) we never used. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I am not at war with Russia. Я не воюю с Россией. Ich bin nicht im Krieg mit Russland.
On Fri, Mar 8, 2024 at 5:01 AM Matthias Apitz <guru@unixarea.de> wrote:
El día viernes, marzo 08, 2024 a las 12:56:16 -0800, Christophe Pettus escribió:
>
>
> > On Mar 8, 2024, at 00:53, Matthias Apitz <guru@unixarea.de> wrote:
> > It does not say definitely that for all other versions a dump/restore is
> > required.
>
> You cannot just replace the binaries to upgrade from an earlier major version to 16.X. The release notes use "a dump/restore (is/is not) required" to indicated whether you can just replace the binaries ("is not") and restart the server on the same database files.
>
I know we can't just switch the binaries and restart the server. We're
compiling the PostgreSQL software by our own (even with some small
changes in the C-code) and deliver the full tree as
/usr/local/sisis-pap/pgsql-11.1
/usr/local/sisis-pap/pgsql-14.1
/usr/local/sisis-pap/pgsql-15.1
...
Also the migration path for customers is described and based on
pg_dumpall, setup a new cluster fromm the above new version and load the
dump with the new psql command into. The other option (pg_upgrade) we
never used.
Upgrading onto a new Linux server (try logical replication or pg_dump -Fd --jobs=), or staying on the old server (pg_upgrade)?
On Fri, Mar 8, 2024 at 5:01 AM Matthias Apitz <guru@unixarea.de> wrote:
The other option (pg_upgrade) we never used.
You really should give this a shot. Much easier, and orders of magnitude faster with the --link option. It should work fine even with a custom-compiled postgres (really, as long as pg_dump can still read things and core changes are not radical). Try it and see.
Cheers,
Greg
On 3/8/24 00:53, Matthias Apitz wrote: > > Hello, > > We plan to update our customers on SuSE Linux from 11.4, 13.1, 14.1 and > 15.1 to 16.2. Do I understand the release notes correct that for this > the way is only dump/restore? The release notes say: > > https://www.postgresql.org/docs/release/16.2/ > ... > . > ... > It does not say definitely that for all other versions a dump/restore is > required. In the current versioning scheme(10+) the version is X.x where X is major version and x is minor version. Any time you move from a major to a major version the binaries are not guaranteed to be compatible and you will need to do a dump/restore, pg_upgrade or logical step to move to the new version. A minor to minor upgrade within a major version in general does not require those steps. The 'A dump/restore is not required for those running 16.X' note is there in case there is an instance when a dump/restore is needed in which case it would be changed to '... is required ...' . This is the case in the development releases of a new version(before X.0) where you usually do have to dump/restore, etc between minor version changes. The note is there to remove any ambiguity. > > We could even unload in the databases the ~400 tables to COPY format, > re-create the tables in a new 16.2 server and load the ~400 files (all this > relatively easy per scripts we created to migrate from Sybase and Oracle > to PostgreSQL). But I think, producing the dump with the old version, > setup new cluster and load the dump with the 16.2 sql command will work. > > Any comments? > > matthias > > -- Adrian Klaver adrian.klaver@aklaver.com