Re: Shared row locking

BTom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > You mean all empty/zero rows can be removed?  Can we guarantee that on
> > commit we can clean up the bitmap?  If not the idea doesn't work.
> 
> For whatever data structure we use, we may reset the structure to empty
> during backend-crash recovery.  So your objection boils down to "what if
> a backend exits normally but forgets to clean up its locks?"  Assuming
> that doesn't happen isn't any worse than assuming a backend will clean
> up its shared memory state on non-crash exit, so I don't think it's a
> serious concern.
> 
> That brings another thought: really what this is all about is working
> around the fact that the standard lock manager can only cope with a
> finite number of coexisting locks, because it's working in a fixed-size
> shared memory arena.  Maybe we should instead think about ways to allow
> the existing lock table to spill to disk when it gets too big.  That
> would eliminate max_locks_per_transaction as a source of hard failures,
> which would be a nice benefit.

Agreed. Once concern I have about allowing the lock table to spill to
disk is that a large number of FOR UPDATE locks could push out lock
entries used by other backends, causing very poor performance.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073