Re: Fix slot synchronization with two_phase decoding enabled
Nisha Moond <nisha.moond412@gmail.com>
From: Nisha Moond <nisha.moond412@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
shveta malik <shveta.malik@gmail.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-05T10:45:14Z
Lists: pgsql-hackers
On Wed, Jun 4, 2025 at 11:16 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Sun, Jun 1, 2025 at 10:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > The one more combination to consider is when someone takes a dump of > > an older version and loads it into a newer version. For example, where > > users dump from 17.5 and then restore in a newer version, say 17.6 > > (which has our fix), the restore will fail due to newer restrictions > > added by this patch. Do we need to do anything about it? > > A valid concern. Implementing this change could potentially render > dumps created prior to version 17.5 incompatible with version 17.6 or > later, which seems a significant backwards incompatibility to me. Do > we have any precedence of such incompatibility? > As per the upgrade documentation[1]: - For major version upgrades, it is recommended to use the pg_dump (and pg_dumpall) from the newer version of Postgres. - For minor version upgrades, it is clearly mentioned to use binary replacement. i.e. - simply shut down the server, replace the binaries, and restart - as minor versions are binary-compatible and do not change the storage format. As per the pg_dump documentation[2]: "Because pg_dump is used to transfer data to newer versions of PostgreSQL, the output of pg_dump can be expected to load into PostgreSQL server versions newer than pg_dump's version." By looking at both the docs[1][2], we can draw the conclusion that the above statement from the pg_dump docs[2] is true for the major version and thus our fix should be safe in that context. [1] https://www.postgresql.org/docs/current/upgrading.html [2] https://www.postgresql.org/docs/14/app-pgdump.html -- Thanks, Nisha
Commits
-
Don't retreat slot's confirmed_flush LSN.
- ad5eaf390c58 18.0 landed
- 7318f241d29c 17.6 landed
- c0f51fde534d 16.10 landed
- 9d1a62359606 15.14 landed
- e68459489c20 14.19 landed
- e323d9df002d 13.22 landed
-
Fix assertion failure during decoding from synced slots.
- 3ff2a1f0c9e8 18.0 landed
-
Fix xmin advancement during fast_forward decoding.
- d65485b02b1f 13.21 landed
- aaf9e95e8764 18.0 landed
- 36148b22ee09 17.5 landed
- 21a7caeeb948 16.9 landed
- f6429bd7db5e 15.13 landed
- 1f63b3626a52 14.18 landed
-
Fix slot synchronization for two_phase enabled slots.
- 4868c96bc8c6 18.0 landed
-
Again match pg_user_mappings to information_schema.user_mapping_options.
- b6e39ca92eee 9.4.13 cited