Re: BUG #18165: Could not duplicate handle for "Global/PostgreSQL.xxxxxxxxxx": Bad file descriptor
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, maxime.boyer@cra-arc.gc.ca, pgsql-bugs@lists.postgresql.org
Date: 2023-10-21T01:34:00Z
Lists: pgsql-bugs
On Sat, Oct 21, 2023 at 2:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2023-10-20 18:16:04 -0400, Tom Lane wrote: > >> That must be coming from dsm_impl_pin_segment or dsm_impl_unpin_segment; > >> noplace else has the same error message spelling. > > > I guess we might now parallelize queries that we didn't in 11 and thus it's > > more likely that we end up needing the typmod registry? > > Maybe. Disabling parallel queries should be an easy stopgap workaround, > in any case. Yeah. Some initial observations about the error: it's dsm_impl_pin_segment(), not dsm_impl_unpin_segment() (kinda strange that we have the same error message for the latter given that it's trying to close it, but anyway here we can see the line number in the OP's report). Both callers of dsm_pin_segment() are immediately after dsm_create(), so we're dealing with an inability to pin a freshly allocated memory object. The way we pin in Windows is that we duplicate the handle into the postmaster for safe-keeping, to keep its refcount (the kernel's refcount, not ours) from reaching zero, and then we unpin by closing that dup'd handle in the postmaster. Perhaps there are two handles that could be b0rked there, triggering an error message like that: the postmaster process handle, and the memory object handle.
Commits
-
Fix min_dynamic_shared_memory on Windows.
- fb9a16a1a6f2 14.10 landed
- f72790b2952d 15.5 landed
- 174ccda5e287 16.1 landed
- dab889d60bac 17.0 landed
-
Fix huge_pages on Windows
- fdd8937c071e 16.0 cited
-
Preallocate some DSM space at startup.
- 84b1c63ad418 14.0 cited