Merlin, > Why even bother with a hash function when you can just have multiple > table pull from a shared sequence? AFAICT, this solves the OP's > problem with no downsides (I used the approach with excellent results > in a ported cobol app which had pessimistic locking requirement).
Well, if you have enough tables, the sequence itself becomes a bottleneck (yes, I've had this happen in an app where all tables shared one sequence). There's also the fact that such a solution is extremely hard to retrofit onto an existing application. It also offends my sense of good database design, but that's another issue entirely. More importantly, I think the issues raised here cause developers not to use advisory locks and instead use solutions more subject to race conditions, like a locking table. Advisory locks could be a really cool feature for developers if it was just a bit more usable. But, as others have pointed out, increasing the size of the lock namespace would cause huge issues elsewhere. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
