I'm trying to catch up on all of this dynamic shared memory stuff. A
bunch of random questions and complaints:
What kind of usage are we trying to cater with the dynamic shared
memory? How many allocations? What size will they have have typically,
minimum and maximum? I looked at the message queue implementation you
posted, but I wonder if that's the use case you're envisioning for this,
or if you have more things in mind.
* dsm_handle is defined in dsm_impl.h, but it's exposed in the function
signatures in dsm.h. ISTM it should be moved to dsm.h
* The DSM API contains functions for resizing the segment. That's not
exercised by the MQ or TOC facilities. Is that going to stay dead code,
or do you envision a user for it?
* dsm_impl_can_resize() incorrectly returns false for DSM_IMPL_MMAP. The
mmap() implementation can resize.
* This is an issue I've seen for some time with git master, while
working on various things. Sometimes, when I kill the server with
CTRL-C, I get this in the log:
^CLOG: received fast shutdown request
LOG: aborting any active transactions
FATAL: terminating connection due to administrator command
LOG: autovacuum launcher shutting down
LOG: shutting down
LOG: database system is shut down
LOG: could not remove shared memory segment "/PostgreSQL.1804289383":
Tiedostoa tai hakemistoa ei ole
(that means ENOENT)
And I just figured out why that happens: If you take a base backup of a
running system, the pg_dynshmem/state file is included in the backup. If
you now start up a standby from the backup on the same system, it will
"clean up" and reuse the dynshmem segment still used by the master
system. Now, when you shut down the master, you get that message in the
log. If the segment was actually used for something, the master would
naturally crash.
* As discussed in the "Something fishy happening on frogmouth" thread, I
don't like the fact that the dynamic shared memory segments will be
permanently leaked if you kill -9 postmaster and destroy the data directory.
- Heikki
