Re: 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,
Pennsylvania19026