| 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-11 20:57:05 |
| Message-ID: | CA+Tgmob9xCcs1w0TAtoHDLaHu9Ca1WZErHE_z5PM46b7S5SAbw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 10, 2021 at 9:26 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> The docs currently say (introduced in commit 91fa853):
>
> "In the event of a backend-detected error during copy-both mode, the
> backend will issue an ErrorResponse message, discard frontend messages
> until a Sync message is received, and then issue ReadyForQuery and
> return to normal processing."
>
> But that doesn't seem to be correct: Sync is only used for the extended
> query protocol, and CopyBoth can only be initiated with the simple
> query protocol.
My impression was that CopyBoth can be initiated either way, but if
you use the extended query protocol, then the result is a hopeless
mess, because the protocol is badly designed:
But I think you're correct in saying that the discard-until-Sync
behavior only happens if the extended query protocol is used, so I
agree that the current text is wrong.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-06-11 21:01:56 | Re: postgres_fdw batching vs. (re)creating the tuple slots |
| Previous Message | Andres Freund | 2021-06-11 20:43:51 | Re: Question about StartLogicalReplication() error path |