Re: Fast DSM segments

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Fast DSM segments
Дата
Msg-id CA+hUKGJpK6QXg1YCYJD7Dg0rbbphHBc4zL5f2Fu6y6UgSX2SCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fast DSM segments  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fix minor source code comment mistake
Следующее
От: Kasahara Tatsuhito
Дата:
Сообщение: Re: autovac issue with large number of tables