Re: shared memory release following failed lock acquirement.

"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> I was wondering how ~ 10k locks ran me out of shared memory when each
> lock takes ~ 260b (half that, as you say) and I am running 8k buffers =
> 64M.

The number of buffers you have doesn't have anything to do with this.
The question is how much shared memory space is there for the lock
table, above and beyond what's used for everything else (such as
buffers).

I just went through and corrected some minor errors in the calculation
of shared memory block size (mostly stuff where the estimation code had
gotten out of sync with the actual work over time). I now find that
with all-default configuration parameters I can create 7808 locks before
running out of shared memory, rather than the promised 6400. (YMMV due
to platform-specific differences in MAXALIGN, sizeof(pointer), etc.)
This is coming from two places: LockShmemSize deliberately adds on 10%
slop factor to its calculation of the lock table size, and then
CreateSharedMemoryAndSemaphores adds on 100KB for safety margin. Both
of those numbers are kinda pulled from the air, but I don't see a strong
reason to change them. The other space calculations seem to be pretty
nearly dead-on.

regards, tom lane