Horton

Re: Fix slot synchronization with two_phase decoding enabled

shveta malik <shveta.malik@gmail.com>

View thread View on postgr.es
From: shveta malik <shveta.malik@gmail.com>
To: Masahiko Sawada <sawada.mshk@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>, shveta malik <shveta.malik@gmail.com>
Date: 2025-06-12T04:49:57Z
Lists: pgsql-hackers 
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.

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.

[1]: https://www.postgresql.org/docs/current/upgrading.html
[2]: https://www.postgresql.org/docs/current/upgrading.html#UPGRADING-VIA-PGDUMPALL

thanks
Shveta

Commits

  1. Don't retreat slot's confirmed_flush LSN.

  2. Fix assertion failure during decoding from synced slots.

  3. Fix xmin advancement during fast_forward decoding.

  4. Fix slot synchronization for two_phase enabled slots.

  5. Again match pg_user_mappings to information_schema.user_mapping_options.