| From: | Bryan Green <dbryan(dot)green(at)gmail(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, harrisontbooth(at)gmail(dot)com |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Fix socket handle inheritance on Windows |
| Date: | 2026-11-01 20:03:51 |
| Message-ID: | 35252fe3-d649-4b42-a951-6890be7321e1@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/6/2025 7:59 PM, Thomas Munro wrote:
> On Fri, Nov 7, 2025 at 2:35 PM Bryan Green <dbryan(dot)green(at)gmail(dot)com> wrote:
>> If you agree, and I think you do, I will implement the SOCK_CLOEXEC
>> abstraction and the socket_set_cloexec helper for this. My bug fix will
>> be the first user.
>
> +1
>
> Thanks for working on all this stuff.
>
>> I also need to handle the handles for shared memory and pipes. I will
>> probably just write those up tonight and share for review and discussion.
>
> Cool.
After a long wait... here's v2! It's two patches now. 0002 is the
shared memory fix I said would follow back in November.
0001 does sockets the way Thomas suggested. Backend code on Windows
now gets a SOCK_CLOEXEC, which pgwin32_socket() maps to
WSA_FLAG_NO_HANDLE_INHERIT, so you ask for a non-inheritable socket
the same way you do on Unix instead of v1's blanket change. The listen
sockets ask for it.
The macro is backend-only, since libpq passes SOCK_CLOEXEC whenever
it's defined and Winsock would reject it. I left accept4() out. It
only matters once we have threads.
Regarding 0002, the postmaster made its shared memory handle
inheritable on purpose, so children could use the same handle value.
That also gave it to everything the children run. If the server dies
while one of those is still running, the next postmaster fails with
"pre-existing shared memory block is still in use". Now the
postmaster's handle isn't inheritable, and save_backend_variables()
duplicates it into each child, the way the signal pipe already is.
Neither copy in the child is inheritable. That covers every child, not
just backends.
The test (src/test/postmaster/t/005_handle_inheritance.pl) uses
Harrison's idea of running the program with server-side COPY TO
PROGRAM. v1's test used \copy, which made the program psql's child, so
it couldn't have caught anything. The program is a small Perl script
that outlives an immediate stop. 0001 checks that the client sees its
connection drop and that the port can be bound again-- 0002 adds a
restart. All fail on master and pass with the patches. Tested with
MSVC on Windows 11 (regress, recovery, isolation, postmaster, pg_ctl,
libpq).
Harrison, thanks for looking at this. I didn't need force_initdb here.
If you saw failures without it, what were they?
--
Bryan Green
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Cagri Biroglu | 2026-11-01 20:05:10 | Re: Per-table resync for logical replication subscriptions |
| Previous Message | Tomas Vondra | 2026-11-01 19:46:24 | Two bugs in reconsider_full_join_clause(), handling coalesce() = const clauses |