On Tue, Jul 20, 2010 at 1:50 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > I'm not sure what kind of resistance you'll see to the idea of a > dynamically allocatable shmem area. Maybe we could use this in other > areas such as allocating space for heavyweight lock objects. Right now > the memory usage for them could grow due to a transitory increase in > lock traffic, leading to out-of-memory conditions later in other > modules. We've seen reports of that problem, so it'd be nice to be able > to fix that with this infrastructure.
Well, you can't really fix that problem with this infrastructure, because this infrastructure only allows shared memory to be dynamically allocated from a pool set aside for such allocations in advance. If a surge in demand can exhaust all the heavyweight lock space in the system, it can also exhaust the shared pool from which more heavyweight lock space can be allocated. The failure might manifest itself in a totally different subsystem though, since the allocation that failed wouldn't necessarily be a heavyweight lock allocation, but some other allocation that failed as a result of space used by the heavyweight locks. It would be more interesting if you could expand (or contract) the size of shared memory as a whole while the system is up and running. Then, perhaps, max_locks_per_transaction and other, similar GUCs could be made PGC_SIGHUP, which would give you a way out of such situations that didn't involve taking down the entire cluster. I'm not too sure how to do that, though. With respect to imessages specifically, what is the motivation for using shared memory rather than something like an SLRU? The new LISTEN implementation uses an SLRU and handles variable-size messages, so it seems like it might be well-suited to this task. Incidentally, the link for the imessages patch on the CommitFest page points to http://archives.postgresql.org/message-id/ab0cd52a64e788f4ecb4515d1e6e4...@localhost - which is the dynamic shmem patch. So I'm not sure where to find the latest imessages patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers