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
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 |