At 01:26 PM 11-01-2001 -0500, Tom Lane wrote:
>Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
>> GETLOCK "string" will lock on "string", the lock being only released at the
>> end of a transaction.
>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
But doesn't that go well with SQL :). The joys of INSERT vs UPDATE.
And "select .. for update" too! So far I haven't left out any "for
updates", at least I think so ;).
I did consider using select for update to simulate it but it doesn't work
when the values are very variable.
>application-level lock. So, as Vadim remarked, doing the insert and
>rolling back to a savepoint on failure would be a much better answer.
Yep, savepoints will allow better consistency. But a getlock feature can be
very handy in lots of other scenarios.
>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.
Looks interesting. Probably what it does is similar enough to what I'm
trying to do. Copy from the best :).
But meantime, back to lock table...
Cheerio,
Link.