Re: walsender termination error messages worse in v10
Petr Jelinek <petr.jelinek@2ndquadrant.com>
From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Peter Eisentraut <peter_e@gmx.net>
Date: 2017-06-02T22:55:22Z
Lists: pgsql-hackers
Attachments
- libpqwalsender-disconnect-fix.diff (invalid/octet-stream) patch
On 02/06/17 23:45, Andres Freund wrote: > Hi Petr, > > On 2017-06-02 22:57:37 +0200, Petr Jelinek wrote: >> On 02/06/17 20:51, Andres Freund wrote: >>> I don't understand why the new block is there, nor does the commit >>> message explain it. >>> >> >> Hmm, that particular change can actually be reverted. It was needed for >> one those custom replication commands which were replaced by normal >> query support. I have missed it during the rewrite. > > Doesn't appear to be quite that simple, I get regression test failures > in that case. > Hmm, looks like we still use it for normal COPY handling. So basically the problem is that if we run COPY TO STDOUT and then consume it using the libpqrcv_receive it will end with normal PGRES_COMMAND_OK but we need to call PQgetResult() in that case otherwise libpq thinks the command is still active and any following command will fail, but if we call PQgetResult on dead connection we get that error you complained about. I guess it would make sense to do conditional exit on (PQstatus(streamConn) == CONNECTION_BAD) like libpqrcv_PQexec does. It's quite ugly code-wise though. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Again report a useful error message when walreceiver's connection closes.
- 5fd56b9f5b4a 10.0 landed
-
Logical replication support for initial data copy
- 7c4f52409a8c 10.0 cited