Re: Replication protocol doc fix

On Wed, Jun 16, 2021 at 5:15 PM Jeff Davis <pgsql@j-davis.com> wrote:
> * A normal command, where you know that you've sent everything that you
> will send. In this case, the client needs to send the Sync message in
> order to get the ReadyForQuery message.
>
> * A command that initiates CopyIn/CopyBoth, where you are going to send
> more data after the command. In this case, sending the Sync eagerly is
> wrong, and you can't pipeline more queries in the middle of
> CopyIn/CopyBoth mode. Instead, the client should send Sync after
> receiving an ErrorResponse, or after sending a CopyDone/CopyFail
> (right?).

Well, that's one view of it. I would argue that the protocol ought not
to be designed in such a way that the client has to guess what
response the server might send back. How is it supposed to know? If
the user says, hey, go run this via the extended query protocol, we
don't want libpq to have to try to parse the query text and figure out
whether it looks COPY-ish. That's expensive, hacky, and might create
cross-version compatibility hazards if, say, a new replication command
that uses the copy protocol is added. Nor do we want the user to have
to specify what it thinks the server is going to do. Right now, we
have this odd situation where the client indeed does not try to guess
what the server will do and always send Sync, but the server acts as
if the client is doing what you propose here - only sending the
CopyDone/CopyFail at the end of everything associated with the
command.

> One thing I don't fully understand is what would happen if the client
> issued the Sync as the *first* message in an extended-protocol series.

I don't think that will break anything, because I think you can send a
Sync message to try to reestablish protocol synchronization whenever
you want. But I don't think it will accomplish anything either,
because presumably you've already got protocol synchronization at the
beginning of the sequence. The tricky part is getting resynchronized
after you've done some stuff.

> I attached a doc patch that hopefully clarifies this point as well as
> the weirdness around CopyIn/CopyBoth and the extended protocol. I
> reorganized the sections, as well.

On a casual read-through this seems pretty reasonable, but it
essentially documents that libpq is doing the wrong thing by sending
Sync unconditionally. As I say above, I disagree with that from a
philosophical perspective. Then again, unless we're willing to
redefine the wire protocol, I don't have an alternative to offer.

-- 
Robert Haas
EDB: http://www.enterprisedb.com