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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html