Tom Lane wrote:
> 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.
You're right that it's ugly, but at least it'd be a temporary "solution" for the fact that we cannot catch
exceptions in triggers yet. So the if/else logic will currently not work reliable in a trigger without beeing
ableto lock before the SELECT.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #