Re: introduce dynamic shared memory registry
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
pgsql-hackers@postgresql.org
Date: 2024-01-02T16:31:14Z
Lists: pgsql-hackers
On Tue, Jan 2, 2024 at 11:21 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > Are we expecting, for instance, a 128-bit UUID being used as a key and > > hence limiting it to a higher value 256 instead of just NAMEDATALEN? > > My thoughts were around saving a few bytes of shared memory space that > > can get higher when multiple modules using a DSM registry with > > multiple DSM segments. > > I'm not really expecting folks to use more than, say, 16 characters for the > key, but I intentionally set it much higher in case someone did have a > reason to use longer keys. I'll lower it to 64 in the next revision unless > anyone else objects. This surely doesn't matter either way. We're not expecting this hash table to have more than a handful of entries; the difference between 256, 64, and NAMEDATALEN won't even add up to kilobytes in any realistic scenario, let along MB or GB. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Fix possible NULL pointer dereference in GetNamedDSMSegment().
- 4372adfa24f2 17.0 landed
-
Teach autoprewarm to use the dynamic shared memory registry.
- abb0b4fc03fc 17.0 landed
-
Introduce the dynamic shared memory registry.
- 8b2bcf3f287c 17.0 landed
-
doc: Reorganize section for shared memory and LWLocks.
- 964152c476f2 17.0 landed