Re: Replication protocol doc fix

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication protocol doc fix
Date: 2021-06-30 16:25:48
Message-ID: CA+Tgmoa1qWkRNgXvv5VCJxXzdrTTTT+dHgp0xTxsT4QEx9ZO4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 17, 2021 at 7:37 PM Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-06-30 16:35:16 Re: Have I found an interval arithmetic bug?
Previous Message Tom Lane 2021-06-30 16:06:47 Re: Preventing abort() and exit() calls in libpq