> 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
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.
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2009-10-27 16:59:37|
|Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order|
|Previous:||From: Josh Berkus||Date: 2009-10-27 16:36:08|
|Subject: Should we warn users about SETs which have no effect?|