On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Jan 20, 2016 at 2:28 AM, Craig Ringer <cr...@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