On Thu, Jun 17, 2021 at 7:37 PM Jeff Davis <pg...@j-davis.com> wrote:
> What if we simply mandate that a Sync must be sent before the server
> will respond with CopyInResponse/CopyBothResponse, and the client must
> send another Sync after CopyDone/CopyFail (or after receiving an
> ErrorResponse, if the client isn't going to send a CopyDone/CopyFail)?
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. 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. 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
