From: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, Rod Taylor <rod(dot)taylor(at)inquent(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: User locks code |
Date: | 2001-08-21 06:26:06 |
Message-ID: | 3.0.5.32.20010821142606.01037a40@192.228.128.13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
At 09:39 AM 20-08-2001 -0700, Mikheev, Vadim wrote:
>> If it does then one of the things I'd use it for is to insert
>> unique data without having to lock the table or rollback on
>> failed insert (unique index still kept as a guarantee).
>
>(Classic example how could be used SAVEPOINTs -:))
I guess so. But this could be faster.
>So, in your application you would first lock a key in excl mode
>(for duration of transaction), than try to select and insert unless
>found? (Note that this will not work with serializable isolevel.)
yep:
lock "tablename.colname.val=1"
select count(*) from tablename where colname=1
If no rows, insert, else update.
(dunno if the locks would scale to a scenario with hundreds of concurrent
inserts - how many user locks max?).
Why wouldn't it work with serializable isolevel?
Anyway, I believe that isolevel doesn't really serialise things in this
case (inserting a unique row) so it wouldn't matter to me.
Regards,
Link.
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Mascari | 2001-08-21 07:16:55 | Re: Sort by foreign date column |
Previous Message | Oliver Elphick | 2001-08-21 06:05:20 | Re: GUI Application mode |
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2001-08-21 06:36:09 | Re: PL/pgSQL bug? |
Previous Message | Tatsuo Ishii | 2001-08-21 01:00:50 | Re: encoding: ODBC, createdb |