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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to