Re: Reapply graceful socket shutdown on Windows (revert 29992a6a509)

From: Greg Burd <greg(at)burd(dot)me>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org, x4mmm(at)yandex-team(dot)ru, thomas(dot)munro(at)gmail(dot)com, nik(at)postgres(dot)ai
Subject: Re: Reapply graceful socket shutdown on Windows (revert 29992a6a509)
Date: 2026-10-30 12:48:56
Message-ID: auSRQOmKKSad6Oca@floki
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Zsolt,

A data point for this, from chasing a cfbot failure on my own entry.

Since about October 24 the cfbot's "Windows - MinGW - Meson" job has
failed now and then in postmaster/002_connection_limits and
libpq/005_negotiate_encryption, on entries that touch neither (at least
5988, 6119, 7203 and 5556). Both fail the same way: the client reports
"server closed the connection unexpectedly" where the test expects the
FATAL the server sent, and the server log shows that FATAL was sent.
In 005 that also means libpq never retries with SSL, so the test sees
"connect, authfail -> fail".

I couldn't make it happen by itself on a Windows Server 2022 EC2 host
(MinGW UCRT64, configured as the cfbot job): 160 runs of the two tests,
idle and with every CPU busy, gave no such failure. So I made the race
certain instead, with a test-only change to libpq that sleeps 300 ms in
pqReadData() before the connection is up, so that the backend has sent
its FATAL and exited before the client reads it. On master
(27c844034f8), both builds:

master master + your v1-0002
MinGW 002_connection_limits 0/10 pass 10/10 pass
MinGW 005_negotiate_encryption 0/10 pass 10/10 pass
MSVC 002_connection_limits 0/10 pass 10/10 pass

Without the delay, your patch passed 40/40 runs of each test on MinGW
and 10/10 of 002 on MSVC (MSVC built without OpenSSL, so no 005 there).
The failures on master are exactly the cfbot's, e.g.

not ok 5 - reserved_connections limit: matches
# 'psql: error: connection to server at "127.0.0.1", port 16509
# failed: server closed the connection unexpectedly
# doesn't match '(?^:FATAL: remaining connection slots are
# reserved for roles with the SUPERUSER attribute)'

So these two tests are hitting the abortive-close problem your patch is
about, and they are perhaps easier to reproduce it with than the
isolation tests: they fail every time once the client is a little slow
to read. That doesn't settle Jacob's point about the SSL_shutdown()
exchange; 005 does exercise SSL, and it passed with the patch, but only
under this one way of forcing the race.

The repro aid is attached; it is not meant for commit.

best.

-greg

Attachment Content-Type Size
repro-delay.patch text/plain 591 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Hayato Kuroda (Fujitsu) 2026-10-30 12:37:41 RE: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation