agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedFrom: Danimar Ribeiro <danimaribeiro@gmail.com>
To: pgsql-bugs@lists.postgresql.org
Cc: david.ritter@gmail.com
Subject: Re: BUG #19424: Concurrent PQconnectdb() calls hang on Windows
Date: Sun, 19 Jul 2026 13:20:36 -0300
Message-ID: <660f580d-d47c-418b-8caf-6228c1e1b4e9@gmail.com> (raw)
In-Reply-To: <19424-0ab4342f914b6296@postgresql.org>
References: <19424-0ab4342f914b6296@postgresql.org>
On Tue, Mar 3, 2026 at 4:23 PM, David Ritter wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19424
> Logged by: David Ritter
> Email address: david.ritter@gmail.com
> PostgreSQL version: 18.3
> Operating system: Windows 11
> Description:
>
> Versions affected: libpq 17.4, 18.3 (likely all 17.x+)
>
> Platform: Windows (MSVC 19.x, x86_64). Not reproducible on Linux (RHEL 9,
> tested 1000 runs with 100 threads each).
>
> Description: When multiple threads each call PQconnectdb() concurrently with
> independent connection strings, most or all threads hang indefinitely.
> PQisthreadsafe() returns 1. A single serial warmup connection succeeds. The
> attached reproducer spawns N threads and reports how many complete within 30
> seconds.
>
>
Hi David,
I was looking into this report and tried to reproduce the issue on
Windows 11 with MSVC, testing against both the latest master and
REL_17_STABLE.
It turns out this isn't a bug in libpq, but rather a limitation in the
Windows API used within the test reproducer script itself.
The `WaitForMultipleObjects` function in Windows has a hardcoded limit
of `MAXIMUM_WAIT_OBJECTS` (which is 64). Because the script passes 100
threads to it at once, the function fails and returns instantly.
Consequently, the script's timer immediately ends while the threads are
still spinning up, reading their `done` flags as 0. The script
misinterprets this instant API failure as a 30-second timeout/hang.
I modified the test script to wait in chunks of 60 threads to bypass the
Windows limit:
for (i = 0; i < num_threads; i += 60) {
int chunk_size = (num_threads - i > 60) ? 60 : (num_threads - i);
WaitForMultipleObjects(chunk_size, &threads[i], TRUE,
TIMEOUT_SECONDS * 1000);
}
After applying this fix to the test script, I ran it with 300 concurrent
threads. The issue disappears completely, and the result is `300 OK`
with zero hung threads. libpq handles the concurrency safely on Windows.
Are you still experiencing this issue in your actual application? If so,
could you provide an updated script to replicate the issue? I would be
happy to test it again.
Regards
Danimar
view thread (2+ messages)
Message-ID: <660f580d-d47c-418b-8caf-6228c1e1b4e9@gmail.com>
Permalink: ../660f580d-d47c-418b-8caf-6228c1e1b4e9@gmail.com/
Also on: postgresql.org/message-id/660f580d-d47c-418b-8caf-6228c1e1b4e9@gmail.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: danimaribeiro@gmail.com, pgsql-bugs@lists.postgresql.org, david.ritter@gmail.com
Subject: Re: BUG #19424: Concurrent PQconnectdb() calls hang on Windows
In-Reply-To: <660f580d-d47c-418b-8caf-6228c1e1b4e9@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox