Re: [PATCH] Preserve replication origin OIDs in pg_upgrade

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Ajin Cherian <itsajin(at)gmail(dot)com>
Cc: Rui Zhao <zhaorui126(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: [PATCH] Preserve replication origin OIDs in pg_upgrade
Date: 2026-07-29 03:58:37
Message-ID: CAJpy0uAz64iQtovGK1ccaLs6oCmg9kfwjRRyWDxiyeyKL=nD5g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 27, 2026 at 4:16 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> On Mon, Jul 27, 2026 at 1:21 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Sun, Jul 26, 2026 at 9:03 PM Rui Zhao <zhaorui126(at)gmail(dot)com> wrote:
> > > So if the skip stays as it is, the count should follow it -- counting only
> > > status rows whose remote_lsn is non-zero. If instead it goes back to advancing
> > > unconditionally, the two line up on their own and the check needs no change.
> > > Either is fine by me; it's the pair being out of step that seemed worth
> > > mentioning while that behaviour is still being decided.
> > >
> >
> > Okay, I see your point. In that case, I think we should track the
> > origin with lsn = 0x0 rather than skip it. To me, this seems more
> > understandable than counting only the status rows whose remote_lsn is
> > non-zero.
>
> Updated the patch accordingly, also fixed the few documentation
> errors. Attaching v14
>

Thanks for the patches Ajin. I currently have no more comments. I will
pause my review here and may resume once it is picked up for commit
and final review.

thanks
Shveta

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-07-29 04:00:25 Re: lost lock during toasting allows fk violation
Previous Message Neil Chen 2026-07-29 03:45:05 Re: [Patch] Don't stop a `vacuumdb --all` on a connection failure