Re: BUG #18165: Could not duplicate handle for "Global/PostgreSQL.xxxxxxxxxx": Bad file descriptor
От | Thomas Munro |
---|---|
Тема | Re: BUG #18165: Could not duplicate handle for "Global/PostgreSQL.xxxxxxxxxx": Bad file descriptor |
Дата | |
Msg-id | CA+hUKG+W8cPyMpRNoao_bsKBH-2=1KM59sSPh-c3kA=TDyWeVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18165: Could not duplicate handle for "Global/PostgreSQL.xxxxxxxxxx": Bad file descriptor (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18165: Could not duplicate handle for "Global/PostgreSQL.xxxxxxxxxx": Bad file descriptor
|
Список | 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.
В списке pgsql-bugs по дате отправления: