Re: Fast DSM segments - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Fast DSM segments
Date
Msg-id CA+hUKGJpK6QXg1YCYJD7Dg0rbbphHBc4zL5f2Fu6y6UgSX2SCg@mail.gmail.com
Whole thread Raw
In response to Re: Fast DSM segments  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Mon, Jul 27, 2020 at 2:45 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Here's a new version, using the name min_dynamic_shared_memory, which
> sounds better to me.  Any objections?  I also fixed the GUC's maximum
> setting so that it's sure to fit in size_t.

I pushed it like that.  Happy to rename the GUC if someone has a better idea.

I don't really love the way dsm_create()'s code flows, but I didn't
see another way to do this within the existing constraints.  I think
it'd be nice to rewrite this thing to get rid of the random
number-based handles that are directly convertible to key_t/pathname,
and instead use something holding {slot number, generation number}.
Then you could improve that code flow and get rid of several cases of
linear array scans under an exclusive lock.  The underlying
key_t/pathname would live in the slot.  You'd need a new way to find
the control segment itself after a restart, where
dsm_cleanup_using_control_segment() cleans up after the previous
incarnation, but I think that just requires putting the key_t/pathname
directly in PGShmemHeader, instead of a new {slot number, generation
number} style handle.  Or maybe a separate mapped file opened by well
known pathname, or something like that.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fix minor source code comment mistake
Next
From: Kasahara Tatsuhito
Date:
Subject: Re: autovac issue with large number of tables