Re: Fix slot synchronization with two_phase decoding enabled

On Wed, Jun 4, 2025 at 11:16 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Sun, Jun 1, 2025 at 10:25 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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