Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> Did we get anywhere with the sizing of the various shared memory
> structures? Did we find the cause of the "out of shared memory"
> warnings?
The patch you just committed is related to that. Some tuple locks
for summarized transactions were not getting cleaned up. I found
one access to the list not protected by the appropriate LW lock,
which is what this patch fixed. I'm not satisfied that was the only
issue, though; I'm still looking.
> Would it help if we just pre-allocated all the shared memory hash
> tables and didn't allow them to grow?
I've been thinking that it might be wise.
> It's bizarre that the hash table that requests the slack shared
> memory space first gets it, and it can't be reused for anything
> else without a server restart. I feel it would make better to not
> allow the tables to grow, so that you get consistent behavior
> across restarts.
Agreed. I think it was OK in prior releases because there was just
one HTAB in shared memory doing this. With multiple such tables, it
doesn't seem sane to allow unbounded lazy grabbing of the space this
way. The only thing I've been on the fence about is whether it
makes more sense to allocate it all up front or to continue to allow
incremental allocation but set a hard limit on the number of entries
allocated for each shared memory HTAB. Is there a performance-
related reason to choose one path or the other?
-Kevin
