Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> Has anyone any input to offer on adding an arbitrary locking feature?
> Where
> GETLOCK "string" will lock on "string", the lock being only released at the
> end of a transaction.
> Any comments, suggestions or tips would be welcome. It looks like quite a
> complex thing to do - I've only just started looking at the postgresql
> internals and the lock manager.
A lock is basically an entry in a shared hash table, so you could
implement this just by having a different kind of key (ie, the given
string) for these sorts of locks.
However, the whole thing strikes me as more of an ugly kluge than a
clean solution to the real problem. If you're not using a UNIQUE
constraint then you're relying on application logic to guarantee
consistency, which is bad. If you do have a UNIQUE constraint and
want to layer this sort of application lock on top of it, then you
still have the problem of unexpected failures if some instance/portion
of your application does inserts without remembering to get the
application-level lock. So, as Vadim remarked, doing the insert and
rolling back to a savepoint on failure would be a much better answer.
BTW, you should consider whether you couldn't use the existing USERLOCK
feature as a short-term alternative. If you can squeeze the key value
you need to insert into a user lock tag, that will do as well as your
proposed general-string-tag locks.
regards, tom lane