Re: Replication protocol doc fix

On Wed, 2021-06-30 at 12:25 -0400, Robert Haas wrote:
> I am not sure whether this works or not. Holding off cancel
> interrupts
> across possible network I/O seems like a non-starter. We have to be
> able to kill off connections that have wedged.

I was following a pattern that I saw in CopyGetData() and
SocketBackend(). If I understand correctly, the idea is to avoid a
cancel leaving part of a message unread, which would desync the
protocol.

>  Also, if we have to
> postpone sending ErrorResponse until we see the Sync, that's also
> bad:
> I think we need to be able to error out whenever.

I think we could still send an ErrorResponse whenever we want, and then
just ignore messages until we get a Sync (just like for an ordinary
extended protocol sequence).

> But, hmm, maybe it's
> OK to send ErrorResponse either before or after sending
> Copy{In,Both}Response. Then the client knows that if ErrorResponse
> shows up before Copy{In,Both}Response, the server sent it before
> consuming the Sync and will stop skipping messages when it sees the
> Sync; whereas if the ErrorResponse shows up after the
> Copy{In,Both}Response then the client knows the Sync was eaten and it
> has to send another one.

That's what I had in mind.

Regards,
	Jeff Davis