Re: Proposal: Conflict log history table for Logical Replication

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

[1]: https://www.postgresql.org/docs/devel/sql-prepare-transaction.html

--
With Regards,
Amit Kapila.