Re: Lock on arbitrary string feature
От | Lincoln Yeoh |
---|---|
Тема | Re: Lock on arbitrary string feature |
Дата | |
Msg-id | 3.0.5.32.20010112103739.0082b4b0@192.228.128.13 обсуждение исходный текст |
Ответ на | Re: Lock on arbitrary string feature (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: