Re: [PoC] pg_upgrade: allow to upgrade publisher node

On Tue, 2 May 2023, 19:43 Julien Rouhaud, <rjuju123(at)gmail(dot)com> wrote:

> Hi,
>
> On Tue, May 02, 2023 at 12:55:18PM +0200, Alvaro Herrera wrote:
> > On 2023-Apr-07, Julien Rouhaud wrote:
> >
> > > That being said, I have a hard time believing that we could actually
> preserve
> > > physical replication slots. I don't think that pg_upgrade final state
> is fully
> > > reproducible: not all object oids are preserved, and the various
> pg_restore
> > > are run in parallel so you're very likely to end up with small physical
> > > differences that would be incompatible with physical replication.
> Even if we
> > > could make it totally reproducible, it would probably be at the cost
> of making
> > > pg_upgrade orders of magnitude slower. And since many people are
> already
> > > complaining that it's too slow, that doesn't seem like something we
> would want.
> >
> > A point on preserving physical replication slots: because we change WAL
> > format from one major version to the next (adding new messages or
> > changing format for other messages), we can't currently rely on physical
> > slots working across different major versions.
>
> I don't think anyone suggested to do physical replication over different
> major
> versions. My understanding was that it would be used to pg_upgrade a
> "physical cluster" (e.g. a primary and physical standby server) at the same
> time, and then simply starting them up again would lead to a working
> physical
> replication on the new version.
>
> I guess one could try to keep using the slots for other needs (PITR backup
> with
> pg_receivewal or something similar), and then you would indeed have to be
> aware
> that you won't be able to do anything with the new WAL records until you
> do a
> fresh base backup, but that's a problem that you can already face after a
> normal pg_upgrade (although in most cases it's probably quite obvious for
> now
> as the timeline isn't preserved).
>

if what you meant is that the slot may have to send a record generated by
an older major version, then unless I'm missing something the same
restriction could be added to such a feature as what's being discussed in
this thread for the logical replication slots. so only a final shutdown
checkpoint record would be present after the flushed WAL position. it may
be possible to work around that, if there weren't all the other problems I
mentioned.

>