BTom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
