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-21T05:26:46Z
Lists: pgsql-bugs
Attachments
- 0001-Fix-min_dynamic_shared_memory-on-Windows.patch (text/x-patch) patch 0001
On Sat, Oct 21, 2023 at 5:10 PM Thomas Munro <thomas.munro@gmail.com> wrote: > Ahh, I think I might see it. "Global/PostgreSQL.2437152779" is an odd > DSM handle (as in, the low order bit is set). That means that it's a > "main region" DSM segment, of the type that you get if you set > min_dynamic_shared_memory (commit 84b1c63a). That looks potentially > broken on Windows, because we have this extra NT handle sharing stuff > in dsm_impl_pin_segment(), which can't possibly work and should > probably be gated on !is_main_region_dsm_handle(seg->handle). On > every other OS that function does nothing, which would explain how we > didn't notice for so long. > > Maxime, do you have min_dynamic_shared_memory set? And concretely this would be the fix, I think. But I don't have Windows, and for reasons I haven't fathomed I haven't yet managed to reproduce it by pushing a change of default min_dynamic_shared_memory to CI. Is there any chance that a Postgres hacker on Windows could confirm the above theory, and that the attached fixes it?
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