Old thread:
https://www.postgresql.org/message-id/512E427B.9090308%40vmware.com
about commit 3a9e64aa.
On Wed, 2013-02-27 at 19:29 +0200, Heikki Linnakangas wrote:
> Right. I fixed that by adding WL_SOCKET_READABLE, and handling any
> messages that might arrive after the frontend already sent CopyEnd.
> The
> frontend shouldn't send any messages after CopyEnd, until it receives
> a
> CopyEnd from the backend.
It looks like 4bad60e3 may have fixed the problem, is it possible to
just revert 3a9e64aa and allow the case?
Also, the comment added by 3a9e64aa is misleading, because waiting for
a CopyDone from the server is not enough. It's possible that the client
receives the CopyDone from the server and the client sends a new query
before the server breaks from the loop. The client needs to wait until
at least the first CommandComplete.
> In theory, the frontend could already send the next query before
> receiving the CopyEnd, but libpq doesn't currently allow that. Until
> someone writes a client that actually tries to do that, I'm not going
> to
> try to support that in the backend. It would be a lot more work, and
> likely be broken anyway, without any way to test it.
I tried to add streaming replication support (still a work in progress)
to the rust client[1], and I ran into this problem.
The core of the rust client is fully pipelined and async, so it's a bit
annoying to work around this problem.
Regards,
Jeff Davis
[1] https://github.com/sfackler/rust-postgres/
