Matthias Apitz <guru@xxxxxxxxxxx> 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
