Re: [PATCH] pg_upgrade: handle failed nonblocking connects on Windows

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Harrison Booth <harrisontbooth(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] pg_upgrade: handle failed nonblocking connects on Windows
Date: 2026-10-14 15:36:18
Message-ID: 98e15036-7f0d-49a2-be0a-1bcd2e581e16@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13/10/2026 23:58, Harrison Booth wrote:
> pg_upgrade can stall when localhost first reaches a refused IPv6
> endpoint on Windows. Its aggregate select loop omits the exception
> set, so PQconnectPoll does not process the failure and try IPv4. Libpq
> already handles this in its single-socket helper.
>
> The patch handles exceptional readiness in pg_upgrade's existing state
> machine. Its Windows TAP test checks both successful-first IPv4 and
> refused-first localhost fallback, skipping when resolver/refusal
> preconditions are unavailable.
>
> All seven assertions pass on MSVC ARM64, MSVC x64 and MinGW x64. The
> x64 runs use emulation on the ARM64 host. Earlier copied-upgrade tests
> from released 18.0 x64 and official 19rc1 ARM64 also preserve the
> seeded data.

Is there any harm in checking for the exception set on other systems too?

> @@ -344,7 +347,18 @@ select_loop(int maxFd, fd_set *input, fd_set *output)
> *input = save_input;
> *output = save_output;
>
> +#ifdef WIN32
> + /* Winsock reports failed nonblocking connects as exceptions. */
> + exceptions = save_output;
> + i = select(maxFd + 1, input, output, &exceptions, NULL);
> + if (i > 0)
> + {
> + for (unsigned int j = 0; j < exceptions.fd_count; j++)
> + FD_SET(exceptions.fd_array[j], output);
> + }
> +#else
> i = select(maxFd + 1, input, output, NULL, NULL);
> +#endif

Looks wrong to set merge the exception set with the writable set like
that. I think it'd be better to add an 'exceptions' argument to the
function.

As a side-note, I'm not convinced that saving the fdsets and looping
here on EINTR is really worth it, the caller would reconstruct the
fdsets and loop back here anyway if there's no work to do. But that's
not new with this patch.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2026-10-14 16:05:46 Re: log XLogPrefetch stats at end of recovery
Previous Message Zsolt Parragi 2026-10-14 15:29:13 Re: Unlogged materialized views