Re: introduce dynamic shared memory registry
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-01-02T22:49:07Z
Lists: pgsql-hackers
Attachments
- v4-0001-add-dsm-registry.patch (text/x-diff)
Here's a new version of the patch set with Bharath's feedback addressed. On Tue, Jan 02, 2024 at 11:31:14AM -0500, Robert Haas wrote: > 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. Right. -- Nathan Bossart Amazon Web Services: https://aws.amazon.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