On Tue, Oct 20, 2026 at 12:30 AM Masahiko Sawada <[email protected]> wrote: > > On Fri, Oct 16, 2026 at 7:39 AM Nisha Moond <[email protected]> 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.
