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

Re: Can pessimistic locking be emulated?

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Christoph Haller" <ch(at)rodos(dot)fzk(dot)de>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can pessimistic locking be emulated?
Date: 2003-02-27 15:40:20
Message-ID: 303E00EBDD07B943924382E153890E5434A91C@cuthbert.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-hackers
That's my fallback position.  Obviously, this will lead to false
positives depending on server load.  In my case, I'm targeting between
30-50 users so its likely to throw timeouts for various reasons other
than locks even though my queries of interest are generally select a
from b where id = c type of thing.  This is a kludgy solution but its
still better than writing cobol.

The bigger issue is that a timeout will not return the reason the query
timed out.  There are cases where I would like to run a select for
update over a range of records and handle the locked records and
unlocked records differently.  A query that could match locked oids vs
the oids I am interested in would be super.  I could then aggregate my
select for updates into larger queries and reap massive performance
gains.

Another way of putting it is this: waiting for your select to timeout is
kind of like parking in Manhattan: you back your car up until you hit
the next car.  I would sort of like to, uh, look in the rear view mirror
first.

Merlin

> >
> > In other words, if User B attempts to select for update a record
that
> > user A has selected for update, it would be nice if User B's query
> would
> > fail with a NOTICE to act upon.
> >
> No idea if this is of any help, but you may have a look into
> PostgreSQL 7.3 Documentation
> 3.4. Run-time Configuration
> STATEMENT_TIMEOUT (integer)
> Aborts any statement that takes over the specified number of
> milliseconds. A value of zero turns off the timer.
> 
> Regards, Christoph
> 


pgsql-hackers by date

Next:From: Robert TreatDate: 2003-02-27 15:46:56
Subject: Re: Free-space-map management thoughts
Previous:From: Tom LaneDate: 2003-02-27 14:59:05
Subject: Re: Free-space-map management thoughts

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