On Tue, Nov 18, 2025 at 1:46 PM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > Dear hackers, > > > I think it is better to enable preserve order by default - for safety > > reasons. > > Per some discussions on -hackers, I implemented the patch which preserves the > commit ordering on publisher. Let me clarify from the beginning. > > Background > ========== > Current patch, say v1, does not preserve the commit ordering on the publisher > node. > After the leader worker sends a COMMIT message to parallel apply worker, the > leader does not wait to apply the transaction and continue reading messages > from > the publisher node. This can cause that a parallel apply worker assigned > later may > commit earlier, which breaks the commit ordering on the pub node. > > Proposal > ======== > We decided to preserve the commit ordering by default not to break data > between > nodes [1]. The basic idea is that leader apply worker caches the remote_xid > when > it sends to commit record to the parallel apply worker. Leader worker sends > INTERNAL_DEPENDENCY message with the cached xid to the parallel apply worker > before the leader sends commit message to p.a. P.a. would read the DEPENDENCY > message and wait until the transaction finishes. The cached xid would be > updated > after the leader sends COMMIT. > This approach requires less codes because DEPENDENCY message has already been > introduced by v1, but the number of transaction messages would be increased. >
It seems you haven't sent the patch that preserves commit order or the commit message of the attached patch is wrong. I think the first patch in series should be the one that preserves commit order and then we can build a patch that tracks dependencies and allows parallelization without preserving commit order. I feel it may be better to just discuss preserve commit order patch that also contains some comments as to how to extend it further, once that is done, we can do further discussion of the other patch. -- With Regards, Amit Kapila.
