On Mon, Nov 9, 2026 at 11:00 AM Amit Kapila <[email protected]> wrote: > > On Mon, Nov 9, 2026 at 10:17 AM Masahiko Sawada <[email protected]> wrote: > > > > On Tue, Nov 3, 2026 at 2:31 AM Amit Kapila <[email protected]> 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.
