
> I was thinking SET because UPDATE does an auto-lock.

Optimal would imho be a SET that gives a maximum amount of time in seconds 
the client is willing to wait for any lock. But I liked the efficiency of Henryk's code.

> 
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > I can imagine some people wanting this.  However, 7.1 has new deadlock
> > > detection code, so I would you make a 7.1 version and send it over.  We
> > > can get it into 7.2.
> > 
> > I object strongly to any such "feature" in the low-level form that
> > Henryk proposes, because it would affect *ALL* locking.  Do you really
> > want all your other transactions to go belly-up if, say, someone vacuums
> > pg_class?

Yes, if a non batch client already blocked for over x seconds. Of course a more
sophisticated client can send querycancel() but that involves a more complicated
program (threads, timer ...).

> > 
> > A variant of LOCK TABLE that explicitly requests a timeout might make
> > sense, though.

I do not think that a solution for one particular lock is very helpful. If your dml then 
blocks on some unforseen lock (parse, plan ...) , the client is in exactly the situation 
it tried to avoid in the first place.

Andreas

Tue, 17 Apr 2001 10:26:25 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: timeout on lock feature
Added to TODO:

	* Add SET parameter to timeout if waiting for lock too long             
       
> 
> > I was thinking SET because UPDATE does an auto-lock.
> 
> Optimal would imho be a SET that gives a maximum amount of time in seconds 
> the client is willing to wait for any lock. But I liked the efficiency of Henryk's code.
> 
> > 
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > > I can imagine some people wanting this.  However, 7.1 has new deadlock
> > > > detection code, so I would you make a 7.1 version and send it over.  We
> > > > can get it into 7.2.
> > > 
> > > I object strongly to any such "feature" in the low-level form that
> > > Henryk proposes, because it would affect *ALL* locking.  Do you really
> > > want all your other transactions to go belly-up if, say, someone vacuums
> > > pg_class?
> 
> Yes, if a non batch client already blocked for over x seconds. Of course a more
> sophisticated client can send querycancel() but that involves a more complicated
> program (threads, timer ...).
> 
> > > 
> > > A variant of LOCK TABLE that explicitly requests a timeout might make
> > > sense, though.
> 
> I do not think that a solution for one particular lock is very helpful. If your dml then 
> blocks on some unforseen lock (parse, plan ...) , the client is in exactly the situation 
> it tried to avoid in the first place.
> 
> Andreas
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 17 Apr 2001 10:14:14 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: AW: timeout on lock feature
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Added to TODO:
> 	* Add SET parameter to timeout if waiting for lock too long

I repeat my strong objection to any global (ie, affecting all locks)
timeout.  Such a "feature" will have unpleasant consequences.

			regards, tom lane

Tue, 17 Apr 2001 10:48:47 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: timeout on lock feature 
This option will be OPTIONAL.

Tom Lane wrote in message <23613.987518927@sss.pgh.pa.us>...
>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Added to TODO:
>> * Add SET parameter to timeout if waiting for lock too long
>
>I repeat my strong objection to any global (ie, affecting all locks)
>timeout.  Such a "feature" will have unpleasant consequences.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html



Wed, 18 Apr 2001 10:55:19 +0200
"Henryk Szal" <szal@doctorq.com.pl>
Re: AW: timeout on lock feature