Re: Proposal: Conflict log history table for Logical Replication

On Tue, Oct 20, 2026 at 12:30 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, Oct 16, 2026 at 7:39 AM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> >
> > Adding the two_phase check in the apply worker makes sense, and I've
> > done that. Without two_phase, the worker now just waits for the lock.
> > But checking whether prepared transactions exist introduces a race
> > condition because one can appear while the worker is waiting. With
> > parallel apply, another worker of the same subscription can prepare
> > the transaction that the waiting command (e.g. TRUNCATE) is blocked
> > on. If the worker found no prepared transaction and started waiting,
> > it would be stuck behind that command, and could never apply the
> > COMMIT PREPARED that releases the lock. So I added only the two_phase
> > check in the worker, and a comment in lock_conflictlog_relation()
> > explaining why there's no prepared-transaction check.
>
> I'm curious about the reason why we do such treatment only for the
> CLT. IIUC the same situation could happen for normal tables.
>

For normal tables, it is the responsibility of the user to not operate
operations that take conflicting locks on the tables where Prepared
transaction is done, otherwise, it is easy to see such non-detectable
deadlocks even in the single-node system. It is warned in the docs [1]
as well. The reason for a separate handling with CLT is that these are
internally managed tables and users may not be even aware that the
table is updated as part of the Prepare Transaction replication during
apply. As part of this patch, we are just giving ERRORs at a few
places where CLT is involved so that users can take necessary actions.
Even without this patch, I feel allowing DROP Subscription when there
is a pending prepared transaction due to corresponding apply worker is
not a good idea. OTOH, if we feel we can warn users of the Prepare
Transaction's interaction with CLT and let him carefully perform the
operations then that is also fine. What do you think?

[1] - https://www.postgresql.org/docs/devel/sql-prepare-transaction.html
(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.)

--
With Regards,
Amit Kapila.