Re: tests fail on windows with default git settings

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tests fail on windows with default git settings
Date: 2024-07-16 00:22:11
Message-ID: CA+hUKGJ0tdtTiB3bHEU8C=5pyzc5zvDqA8dJ5q+ThSimW8QKNw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 14, 2024 at 10:00 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Jul 12, 2024 at 3:49 AM Dave Page <dpage(at)pgadmin(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-07-16 00:30:22 Re: Logical Replication of sequences
Previous Message David Rowley 2024-07-16 00:21:46 Re: Parent/child context relation in pg_get_backend_memory_contexts()