Re: Fix slot synchronization with two_phase decoding enabled
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: Nisha Moond <nisha.moond412@gmail.com>,
Dilip Kumar <dilipbalaut@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-16T23:46:53Z
Lists: pgsql-hackers
On Wed, Jun 11, 2025 at 9:50 PM shveta malik <shveta.malik@gmail.com> wrote: > > On Wed, Jun 11, 2025 at 11:31 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > BTW have we addressed the point Amit mentioned before[1]? > > > > > 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? > > > > I think it could be a significant side-effect and we need to do > > something about that. > > > > After giving it more thought, we have an opinion that this > side-effect/issue is unlikely to occur if users follow our > documentation properly. > > The recommended approach for upgrading between minor versions is to > shut down the server and replace the binaries. See 'To update between > compatible versions' in [1]. > > Also it is recommended in docs that we use pg_dump from the newer > version of PostgreSQL. See 'It is recommended that you use the > pg_dump' in [2]. This particular recommendation is in the Upgrade doc. > If needed, we can make a similar recommendation in any of our failover > specific docs as well, mentioning this particular case. > > In brief, our overall understanding is that a) pg_dump is mainly used > for major versions upgrade b) pg_dump of higher version is used. > Please let us know if your understanding is different here. I agree that the main use case of pg_dump is major version upgrading but it's not limited to that use case. There might be some users who have taken backups using pg_dump for truly backup purposes. I'm not sure we've had such compatibility breakage in a minor version release. > Beyond these steps, we could not find any better solution for the > pointed case. But we are open to exploring and implementing any > alternative solutions you may have. Feedback is most welcome here. I'll share alternative ideas if I come up. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
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