Message-ID: <0a2c985ebcaa1acd385350aeba561b6509187394.camel@j-davis.com>
Subject: Replication protocol pipelining edge case
From: Jeff Davis <pgsql@j-davis.com>
To: pgsql-hackers@postgresql.org
Date: Tue, 05 Jan 2021 09:17:18 -0800
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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