Replication protocol pipelining edge case

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Replication protocol pipelining edge case
Date: 2021-01-05 17:17:18
Message-ID: 0a2c985ebcaa1acd385350aeba561b6509187394.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The streaming replication protocol docs[1] say (for START_REPLICATION):

"If the client requests streaming at exactly the end of an old
timeline, the server responds immediately with CommandComplete without
entering COPY mode."

Is there a reason we do that? It seems like enough of an edge case that
it's not worth optimizing.

The reason I ask is because it makes clients that do pipelining more
complex. If the server always enters copy mode, then the client can
send a CopyDone and then pipeline more requests behind it. But if the
server may or may not enter copy mode, then the client needs to wait
until it sees a CopyBothResponse before any new requests can be
pipelined.

To be clear, my concern is mainly about the simplicity of the protocol
and the simplicity of clients that support pipelining. I am not arguing
that there's an important use case for pipelining requests in this
manner.

Also, I'm curious if we know about other areas where the protocol
doesn't mix nicely with pipelining.

In a related note, I think the documentation text above is also
incorrect, because streaming from an old timeline will send a tuple
back before CommandComplete.

Regards,
Jeff Davis

[1] https://www.postgresql.org/docs/devel/protocol-replication.html

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2021-01-05 17:19:31 Re: Online checksums patch - once again
Previous Message Jim Finnerty 2021-01-05 16:26:50 Re: Challenges preventing us moving to 64 bit transaction id (XID)?