Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
От | Bruce Momjian |
---|---|
Тема | Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE |
Дата | |
Msg-id | 200410261735.i9QHZDi20823@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE (Robert Treat <xzilla@users.sourceforge.net>) |
Список | pgsql-hackers |
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 pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: