Matthias Apitz <guru@unixarea.de> writes:
> At the end of the day, it turned out that out client caused the problem.
> Because we were hunting some other issue, the client was logging some
> message with fprintf(stderr, ...) but the fd=2 was not stderr, fd=2 was the
> connection to the socket of the PostgreSQL server. And ofc the Pos
> server could not understand our human message.
Hmph. So why wasn't this visible in the tcpdump trace?
My initial thought was that the server process should log a message
and drop the connection once it received something that didn't look
like a valid Postgres-protocol message, on the assumption that
message-boundary sync could never be recovered reliably. But on
further thought, it would start by taking the second through fifth
bytes of the input as a message length, and it wouldn't really do
anything interesting until it had collected that much input ---
and, if those bytes were text, that would look like a large number.
So what the server is really doing is waiting for the rest of the
imaginary message, which will never arrive.
Maybe we should have more sanity checking on alleged message lengths.
I recall there is some checking of that sort in libpq, but I'm less
sure about the server.
regards, tom lane
