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
