On Sun, Jul 14, 2024 at 10:00 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Fri, Jul 12, 2024 at 3:49 AM Dave Page <dp...@pgadmin.org> wrote: > > # doesn't match '(?^:pg_dump: error: connection to server .* failed: > > FATAL: database "qqq" does not exist)' > > Does it help if you revert 29992a6?
FWIW I just happened to notice the same failure on Cirrus, in the github.com/postgres/postgres master branch: https://cirrus-ci.com/task/5382396705505280 Your failure mentions GSSAPI and the above doesn't, but that'd be because for Cirrus CI we have PG_TEST_USE_UNIX_SOCKETS so it's using AF_UNIX. At one point I proposed deleting that weird GSAPPI stuff and using AF_UNIX always on Windows[1], but the feedback was that I should instead teach the whole test suite to be able to use AF_UNIX or AF_INET* on all OSes and I never got back to it. The error does seem be the never-ending saga from this and other threads: https://www.postgresql.org/message-id/flat/90b34057-4176-7bb0-0dbb-9822a5f6425b%40greiz-reinsdorf.de My uninformed impression is that graceful socket shutdowns would very likely fix the class of lost-final-message problem where the client does recv() next, including this case IIUC. It's only a partial improvement though: if the client calls send() next, I think it can still drop buffered received data, so this graceful shutdown stuff doesn't quite get us to the same situation as Unix all points in the protocol. The real world case where that second case comes up is where the client sends a new query and on Unix gets a buffered error message saying the backend has exited due to idle timeout, but on Windows gets a connection reset message. I've wondered before if you could fix (or narrow to almost zero?) that by giving libpq a mode where it calls poll() to check for buffered readable data every single time it's about to send. [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGK30uLx9dpgkYwomgH0WVLUHytkChDgf3iUM2zp0pf_nA%40mail.gmail.com
