On Wed, Jun 1, 2011 at 1:30 AM, Tatsuo Ishii <is...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
