Skip site navigation (1) Skip section navigation (2)

Re: lock - feedback

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Thomas Rokohl" <rokohl(at)raygina(dot)de>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: lock - feedback
Date: 2005-10-12 14:18:32
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3417DD591@Herge.rcsinc.local (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
> > Have you looked at contrib\userlock?  With it, you can simulate
> > pessimistic locks with a non-blocking result code.
> >
> > Merlin
> >
> >
> >
> contrib/userlock? where i can find something about this? in the manual

> can't find something ?!?!
> mhm what is with the "lost update" problem, can i solve it with it?!?!

probably.  However, in many cases proper use of transactions is more
appropriate.  This will be even easier to do when we get proper

> i can't visualize how it can works?
select user_write_lock(oid) from my_table where value = x;
returns 1 on success, 0 on failure.

just be careful...
select user_write_lock(oid) from my_table where value = x order by y
limit 1;
can acquire more locks than you might think since the table has to be
materialized to do the order.

better to write:

select user_write_lock(oid) from 
    select oid, *  from my_table where value = x order by y limit 1;

also, don't use oid :).  In my applications, I make a domain type called
'cuid' which pulls nextval() from a public sequence.  Put that into your
tables and lock on it.  Just watch for dump/restore.



pgsql-odbc by date

Next:From: Thomas RokohlDate: 2005-10-12 14:51:15
Subject: Re: lock - feedback
Previous:From: Richard HuxtonDate: 2005-10-12 13:58:14
Subject: Re: lock - feedback

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group