Re: Replication protocol doc fix - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Replication protocol doc fix
Date
Msg-id CA+Tgmoa1qWkRNgXvv5VCJxXzdrTTTT+dHgp0xTxsT4QEx9ZO4w@mail.gmail.com
Whole thread Raw
In response to Re: Replication protocol doc fix  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Replication protocol doc fix
List pgsql-hackers
On Thu, Jun 17, 2021 at 7:37 PM Jeff Davis <pgsql@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Preventing abort() and exit() calls in libpq
Next
From: Bruce Momjian
Date:
Subject: Re: Have I found an interval arithmetic bug?