From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Conflict detection for update_deleted in logical replication |
Date: | 2025-07-04 06:31:24 |
Message-ID: | CAFiTN-uLF_BOSt-cLFKJyBp_L1MBk0H367-DFbQg2eqmv7pEkw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 3, 2025 at 4:21 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Jul 3, 2025 at 10:57 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > On Thu, Jul 3, 2025 at 10:43 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Thu, Jul 3, 2025 at 10:26 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > >
> > > >
> > > > You changes related to write barrier LGTM, however I have question
> > > > regarding below change, IIUC, in logical replication
> > > > MyReplicationSlot->effective_xmin should be the xmin value which has
> > > > been flushed to the disk, but here we are just setting "data.xmin =
> > > > new_xmin;" and marking the slot dirty so I believe its not been yet
> > > > flushed to the disk right?
> > > >
> > >
> > > Yes, because this is a physical slot and we need to follow
> > > PhysicalConfirmReceivedLocation()/PhysicalReplicationSlotNewXmin().
> > > The patch has kept a comment in advance_conflict_slot_xmin() as to why
> > > it is okay not to flush the slot immediately.
> >
> > Oh right, I forgot its physical slot. I think we are good, thanks.
> >
>
> BTW, I wanted to clarify one more point related to this part of the
> patch. One difference between PhysicalReplicationSlotNewXmin() and
> advance_conflict_slot_xmin() is that the former updates both
> catalog_xmin and xmin for the slot, but later updates only the slot's
> xmin. Can we see any reason to update both in our case?
IMHO the purpose of these 2 functions are different, I think the
PhysicalReplicationSlotNewXmin() update the xmin in response to
hot_standby_feedback and the purpose of that is to avoid removing
anything on primary until it is no longer required by the standby so
that we do not create conflict or query cancellation. So it has to
consider the data required by active queries, physical/logical
replication slots on standby etc. Whereas the purpose of
advance_conflict_slot_xmin() to prevent the tuple from removing on the
subscriber which might required for the conflict detection on this
node, the other aspect of not removing the tuple which is required for
the logical/physical replication slots on this node is already taken
care by other slots. So I think this is a very specific purpose build
slot which just has one specific task, so I feel we are good with what
we have.
--
Regards,
Dilip Kumar
Google
From | Date | Subject | |
---|---|---|---|
Next Message | Ronan Dunklau | 2025-07-04 06:46:08 | Non-blocking archiver process |
Previous Message | Michael Paquier | 2025-07-04 06:29:07 | Re: Add pg_get_injection_points() for information of injection points |