0

I'm curious if PostgreSQL's Group Commit mechanism (controlled by commit_delay and commit_siblings parameters) only affects disk fsync calls.

Or does it also allow multiple on-the-fly transactions to be batched concurrently in WAL synchronous replication?

From here it should affect synchronous replication ("The proposed implementation this page describes is heavily based on the existing synchronous replication implementation. ")?

But here says: "No sleep will occur if fsync is not enabled", so it seems that Group Commit mechanism only reduces local fsync, and does not support batch confirmation of WAL remote synchronous replication?

--------UPDATE:

My understanding: In synchronous (strongly consistent) replication, each commit on the local node waits until the remote standby node returns ack before continuing.

So my question is: During this waiting time for ack signaling (at least one RTT - Round Trip Time):

[A] will the transactions on the concurrent connections of other clients continue to be replicated and committed to the standby node without blocking?

[B] Or does each transaction have to wait for the end of the previous transaction to initiate a commit to the remote standby node (stop-and-wait protocol)?

As you can see, action [A] is much like group commit, and [B] is like no group commit optimization. Coupled with the descriptions on the pg's official wiki (It says "The group commit is heavily based on the existing synchronous replication implementation."), that's why I associate it with group commit optimization.

1 Answer 1

4

commit_delay should have no impact on synchronous replication. No matter how it is set, PostgreSQL waits until the WAL is flushed locally (which may take longer with commit_delay set to a non-zero value), but WAL still gets streamed to the standby, written to disk there and replayed.

The standby server is in recovery, so replaying WAL happens in the single thread of the startup process, and commit_delay has no meaning in this context.

6
  • Thank you for your answer. So PostgreSQL's synchronous replication uses a stop-and-wait protocol? That is: at most 1 transaction can be submitted in each RTT of the network between the primary node and the standby node?
    – ASBai
    Commented Sep 28, 2022 at 5:57
  • I am not sure what a "stop-and-wait protocol" or a "RTT" is. WAL is a sequential stream, which is replayed to the standby sequentially. So a transaction that committed earlier on the primary will get a feedback from the standby earlier. WAL is streamed, so the primary does not wait for feedback from the standby before sending the next WAL record. Streaming WAL and feeback from the standby are not synchronized. Commented Sep 28, 2022 at 6:03
  • My understanding: In synchronous (strongly consistent) replication, each commit on the local node waits until the remote standby node returns ack before continuing. So my question is: [A] During this waiting time for ack signaling (at least one RTT - Round Trip Time), will the transactions on the concurrent connections of other clients continue to be replicated and committed to the standby node without blocking? [B] Or does each transaction have to wait for the end of the previous transaction to initiate a commit to the remote standby node (stop-and-wait protocol)? Thanks :-)
    – ASBai
    Commented Sep 28, 2022 at 21:35
  • As you can see, action [A] is much like group commit, and [B] is like no group commit optimization. Coupled with the descriptions on the pg's official wiki (It says "The group commit is heavily based on the existing synchronous replication implementation."), that's why I associate it with group commit optimization.
    – ASBai
    Commented Sep 28, 2022 at 21:43
  • 1
    Thatks for your explanation. It is [A]: WAL keeps streaming from the primary to the standby, even if one backend is waiting for feedback from the standby. WAL is not separated per transaction or per database, all changes go into the same stream right when they happen. So it is not one backend sending information to the standby, it is the walsender process, and that process doesn't care if repication is synchronous or asynchronous. Commented Sep 29, 2022 at 5:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.