Skip site navigation (1) Skip section navigation (2)

Re: Proposal: String key space for advisory locks

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Christophe Pettus <xof(at)thebuild(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: String key space for advisory locks
Date: 2009-10-27 16:43:20
Message-ID: 4AE72328.4060003@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-10-27 16:59:37
Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Previous:From: Josh BerkusDate: 2009-10-27 16:36:08
Subject: Should we warn users about SETs which have no effect?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group