Re: Inconsistent error handling in START_REPLICATION command

Поиск
Список
Период
Сортировка
От Shulgin, Oleksandr
Тема Re: Inconsistent error handling in START_REPLICATION command
Дата
Msg-id CACACo5Sm-tY-9YijuLbXmcLmSkYtcTaVQh_1j4tADfjC+1-bCw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inconsistent error handling in START_REPLICATION command  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Inconsistent error handling in START_REPLICATION command  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Jan 20, 2016 at 2:28 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> It enters COPY BOTH mode before it invokes the startup callback. The client
> has no way to unilaterally terminate COPY BOTH mode and return to the normal
> walsender protocol. The server doesn't do it when there's an ERROR. So the
> only option the client has for recovery is to disconnect and reconnect.

This isn't my understanding of how the protocol works, and it's not
what the documentation says either.

Per http://www.postgresql.org/docs/current/static/protocol-flow.html:

===
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. The frontend should treat receipt of
ErrorResponse as terminating the copy in both directions; no CopyDone
should be sent in this case.
===

So it's true that the client can't unilaterally terminate COPY BOTH
mode; it can only send CopyDone.  But an error on the server side
should do so.

Hm, you're right.  Even though the server sends COPY_BOTH message before the plugin startup, an attempt by the client to actually read the data messages results in ErrorResponse handled on the client, then the client can re-submit the corrected START_REPLICATION command and continue without the need to reconnect.  This cannot be actually tested in psql, but I can verify the behavior with my python scripts.

Then I don't have a preference for the early error reporting in this case.  If the current behavior potentially allows for more flexible error reporting, I'm for keeping it.

--
Alex

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Inconsistent error handling in START_REPLICATION command
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Expanded Objects and Order By