The dynamic shared memory (DSM) registry (introduced in 8b2bcf3) is a convenient way for PostgreSQL extensions (and core components) to allocate dynamic shared memory and associate it with a string name.

In its initial form (PostgreSQL 17), it only supported allocating DSM segments via the GetNamedDSMSegment function.

Recently, Nathan Bossart in fe07100 introduced two new variants: GetNamedDSA() and GetNamedDSHash(). These simplify allocating Dynamic Shared Areas (DSA) and dynamic shared hash tables (dshash) within the DSM registry itself.

This was already technically possible before, but the ergonomics were inconvenient—these new helpers make it much cleaner.

Personally, I’ve been (ab)using the DSM registry quite a lot because I find it incredibly powerful. With these facilities, you can design really sophisticated interactions, leveraging PostgreSQL’s shared memory to store arbitrary metadata across backends.

But with power comes the need for visibility. It’s only natural to want insight into what’s happening under the hood—especially since PostgreSQL has traditionally offered system views precisely for these use cases.

That’s why I contributed the new pg_dsm_registry_allocations system view. It exposes shared memory allocations tracked in the DSM registry, including memory allocated by extensions using the mechanisms described here.

For each entry in the registry, the view returns: its name, the type of allocation (segment, area, or hash) and the size in bytes (for segment types; NULL for area and hash)

The test_dsm_registry test module serves as a complete usage example for all these facilities.

But the gist of it is: if you have code like this in your extension—

...
tdr_dsm = GetNamedDSMSegment("test_dsm_registry_dsm",
                             sizeof(TestDSMRegistryStruct),
                             init_tdr_dsm, &found);
tdr_dsm->val = ...;

tdr_dsa = GetNamedDSA("test_dsm_registry_dsa", &found);
tdr_dsa->val = ...;

tdr_hash = GetNamedDSHash("test_dsm_registry_hash", &dsh_params, &found);
entry = dshash_find_or_insert(tdr_hash, key, &found);
if (found)
    dsa_free(tdr_dsa, entry->val);

entry->val = dsa_allocate(tdr_dsa, strlen(val) + 1);
strcpy(dsa_get_address(tdr_dsa, entry->val), val);
...

—you can inspect the DSM registry at runtime with a simple SQL query like:

SELECT name, type, size IS DISTINCT FROM 0 AS size
FROM pg_dsm_registry_allocations
WHERE name LIKE 'test_dsm_registry%'
ORDER BY name;

          name          |  type   | size 
------------------------+---------+------
 test_dsm_registry_dsa  | area    | t
 test_dsm_registry_dsm  | segment | t
 test_dsm_registry_hash | hash    | t
(3 rows)

Unfortunately, both these improvements (the new allocation helpers and the system view) landed after the PostgreSQL 18 feature freeze. They’ll be officially available in PostgreSQL 19 (expected Autumn 2026).

If you really need them before then, you can copy and adapt the patches with only minor modifications for your local builds.

Feel free to reach out if you need help with that. Also, let me know if you’re doing something interesting with these facilities—I’m curious!