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 по дате отправления: