There is a statement_timeout that will control how long a statement can
execute before being cancelled. We have never agreed that controlling
how long we wait for an individual lock is valuable.
---------------------------------------------------------------------------
Robert Treat wrote:
> On Thursday 21 October 2004 06:44, you wrote:
> > Hi
> >
> > Was already implemented the timeout on the "SELECT ... FOR UPDATE"
> > (non-blocking lock) and/or is possible known if the lock exist on the
> > specified ROW before executing the SELECT?
> >
>
> No.
>
> > Please note: ours need is the timeout/verify at the ROW level, not at the
> > table level.
> >
> > Is already OK? Is in the TODO list?
> > May you suggest an alternative method?
> >
> > Thank you.
>
> You would need a more extensive implementation of row level locks than
> PostgreSQL currently offers. There have been discussions about this in the
> past, but afaik no one is actively working on it. You can probably find more
> info in the archives about it, also I believe it is on the TODO list, so you
> might find some more detail by looking there.
>
> --
> Robert Treat
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
