On Wed, Jun 1, 2011 at 1:30 AM, Tatsuo Ishii <ishii@postgresql.org> wrote:
>> Problem with the advisory lock is, it will not work if the target
>> table is empty.
>
> Oops. I was wrong. the key for advisory lock needs to be a unique
> value, but not necessarily a row value in a table. Seems this is the
> way I should go(though need to be carefull since the lock is not
> released even after a transaction ends). Thanks!
9.1 has a transactional advisory lock (fyi). I'd still consider
keeping to the old method because presumably you want the lock to be
as short as possible. Another big headache with advisory locks
unfortunately is lockspace conflicts between user code and library
(you) code -- I've actually seen this in the wild once. Maybe you
could use the double int4 version and allow the users to supply the
other optional int4?
merlin
