From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | FATAL: could not send end-of-streaming message to primary: no COPY in progress |
Date: | 2016-03-31 00:15:45 |
Message-ID: | CAEepm=1fEZ7Dt2r-HEp71BL8Bf+HzLmU6gN-yTgH4u7zhxEcXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers,
If you shut down a primary server, a standby that is streaming from it says54:
LOG: replication terminated by primary server
DETAIL: End of WAL reached on timeline 1 at 0/14F4B68.
FATAL: could not send end-of-streaming message to primary: no COPY in progress
Isn't that FATAL ereport a bug?
I haven't worked out the root cause but the immediate problem seems to
be libpqrcv_endstreaming calls PQputCopyEnd which doesn't like the
state that the libpq connection is in, namely PGASYNC_BUSY. That
state seems to have been established by the call to walrcv_receive
that returned -1 (end of copy). It doesn't happen in the similar case
of promotion of the remote server.
How is clean server shutdown supposed to work? It looks like
walsender sends COPY 0 and then just hangs up. Meanwhile, walreceiver
has to distinguish between that case and the the new timeline case
which involves a further exchange of messages. Is an explicit message
at the end of the copy stream saying either "goodbye" or "but wait,
there's more" lacking here? Or is there some other way that
walreceiver could distinguish between clean shutdown of remote server
(no error necessary), unclean shutdown of remote server, and timeline
negotiation?
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2016-03-31 00:20:02 | 9.6 Open Item Ownership |
Previous Message | Josh berkus | 2016-03-30 23:49:53 | So, can we stop supporting Windows native now? |