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