Re: Proposal: Conflict log history table for Logical Replication

On Mon, Nov 9, 2026 at 11:00 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Nov 9, 2026 at 10:17 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Tue, Nov 3, 2026 at 2:31 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > >
> > > Yes, I also thought about it previously and felt the same. To achieve
> > > this we need to scan the lock table for holders on the relation and
> > > match them to the subscription's prepared transactions (their dummy
> > > PGPROCs). See attached top-up atop v88 generated by AI. I can
> > > review/test it more if we decide to go with this strategy. I still
> > > feel we shouldn't add this because such scenarios will be rare in
> > > practice. It won't be difficult to address this if we really see such
> > > field reports, so I would like to leave this code as is but if you
> > > still think otherwise then we can take care with finding whether
> > > prepared xact has locked CLT.
> >
> > I'm not sure it's that rare. Tuples copied by the initial table sync
> > always cause a conflict (update_origin_differs or
> > delete_origin_differs) when the apply worker modifies them for the
> > first time, if track_commit_timestamp is enabled.

As discussed in thread [1] that is a caveat we should fix. When/If we
fix those cases then this shouldn't be a cause of worry and I think we
need to do something about it before we think of resolutions.

> > Also, in systems
> > using two-phase commit, it's common that the subscription has prepared
> > transactions. But I might be worrying too much.
> >

I am also not very clear how much to worry about this case.

> > TBH I'm still not sure why we really need the special behavior of
> > erroring out only for the CLT. I agree that it's an internal behavior
> > and users might not be aware of it, but I think users who don't know
> > it would be equally confused when the apply worker errors out because
> > of it.
> >
>
> I see your point. So, what should we do instead? We can remove this
> extra handling for prepared xact from apply_worker and document it.
> Prepare Transaction already notes as follows: "PREPARE TRANSACTION is
> not intended for use in applications or interactive sessions. Its
> purpose is to allow an external transaction manager to perform atomic
> global transactions across multiple databases or other transactional
> resources. Unless you're writing a transaction manager, you probably
> shouldn't be using PREPARE TRANSACTION.". Then there is a long Caution
> Note [1], shall we document the additional hazards with respect to
> apply worker both for normal and CLT tables?
>

We have discussed two options (a) document it as mentioned above (b)
detect and error out apply worker as currently proposed by patch. Now,
we can argue to implement a larger solution to detect such cases and
consider them as deadlock but I don't think that is a good idea
especially for CLT.

Thoughts?

[1]: https://www.postgresql.org/message-id/19360-1952ab7afd799f70%40postgresql.org

--
With Regards,
Amit Kapila.