Daniel Schuchardt <[EMAIL PROTECTED]> writes: > Tom Lane schrieb: >>> Can I see a stack trace from that? Or at least the verbose form of the >>> error message?
> WARNING: 53200: out of shared memory > LOCATION: ShmemAlloc, shmem.c:185 > STATEMENT: SELECT count(*) FROM art; > ERROR: 53200: out of shared memory > LOCATION: BufTableInsert, buf_table.c:93 > STATEMENT: SELECT count(*) FROM art; Hmm. Okay, I think I see what is going on here. dynahash's HASH_REMOVE operation sticks the freed space into a freelist associated with the particular hashtable, but it never releases it for "general" use (and since we do not have any general-purpose alloc/free code for shared memory, there's really no way it could do that). So what is happening is that the subxact-open loop creates new locktable hash entries until it's run the free space in shared memory down to nil, and then it errors out. The lock hash entries are then released ... but only to the freelist associated with the lock table. If the shared hash table for the buffer pool needs to grow afterwards, it's out of luck. Had you been running the server for very long before forcing the error, I don't think this would have happened, because the buffer hashtable would have already expanded to its full working size. I can think of various tweaks we could make to the hash management code to avoid this scenario, but I'm not sure that any of those cures aren't worse than the disease: they all seem to reduce the flexibility of shared memory allocation instead of increasing it. And I don't want to create a full-fledged alloc/free package for shared memory --- the bang-for-buck ratio for that is way too low. So I'm inclined to leave this alone. Once we fix subxacts to not hold their XID locks after subcommit, the probability of a problem should go back down to the same low value that's allowed us to ignore this risk for the past many years. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match