RE: User locks code

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.

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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