>>>>> "Marcin" == Marcin Barczyński <mba.ogolny@gmail.com> writes:
Marcin> Unfortunately, it's not the problem of verbosity.
Marcin> The error code is printed properly in case of duplicate key
Marcin> violation. It seems that something is wrong with
Marcin> idle-in-transaction timeout on Windows:
I think this is domain-dependent or platform-dependent behavior of the
result of sending data on an already-closed connection.
On Ubuntu, were you using psql -h localhost, or psql with no host
parameter (which uses local-domain sockets by default, whereas with -h
localhost it uses TCP)?
When the server forces a connection to be closed like this, it writes
the ErrorResponse packet, and then closes the connection and ends the
backend process. Since psql does not expect data at that point, the
packet will (at best) remain buffered waiting to be read.
But when you do the next query, I am fairly sure that libpq will _write_
the new query to the connection before checking for any input. If the
connection is via TCP to localhost, that write may well result in an
immediate reset of the connection (since no process is available to read
from the other end), which may cause the buffered data to be discarded
before libpq can read it, so you never see it.
This isn't something we can reasonably fix, it's inherent to how the
network protocol implementations work. Only a client program that's
prepared to check for incoming data on an idle connection (which psql
does not) has any chance of reliably getting the error packet from a
forcibly closed connection (though clients that are not local to the
database host should _usually_ get it even if they do not check).
--
Andrew (irc:RhodiumToad)
