readUnsolicited

Reads whatever the server sent while nobody was reading, without waiting for more.

Between exchanges the server can still speak: a notification, a notice, a parameter that changed - and a FATAL that ended the session while it sat idle, which is how every timeout but the statement's own arrives, and how pg_terminate_backend() reaches an idle session. Reading that one before anything is written is what keeps it. Written first, a statement goes to a backend that has already exited, its host answers with a reset, and a reset lets the TCP stack drop whatever it still held for the connection - a Windows client does exactly that, so the error that explained everything never reaches a read, and the caller is told about a reset instead. That keeps the reason where the server closes the connection gracefully. A stock PostgreSQL on Windows resets it by itself as the backend exits, milliseconds after the FATAL, and a Windows client loses the reason then whatever the driver does, unless this look came first.

Only what has already arrived is read, so an idle connection the server has told nothing costs one look at the socket. On a TLS connection that look reaches only what the TLS layer has already decrypted - bytes still encrypted on the socket cannot be told apart from a record that carries no message - so there a session ended while idle is found where it always was: by the first read after the next write.

Not for use inside an exchange or a transfer, where what is waiting is the answer to what was sent.

Throws