Re: AW: timeout on lock feature - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: AW: timeout on lock feature
Date
Msg-id 200104181858.f3IIwgW14130@candle.pha.pa.us
Whole thread Raw
In response to RE: AW: timeout on lock feature  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
[ Charset ISO-8859-1 unsupported, converting... ]
> > This is the real reason why I've been holding out for restricting the
> > feature to a specific LOCK TABLE statement: if it's designed that way,
> > at least you know which lock you are applying the timeout to, and have
> > some chance of being able to estimate an appropriate timeout.
> 
> As I pointed before - it's half useless.
> 
> And I totally do not understand why to object feature
> 
> 1. that affects users *only when explicitly requested*;
> 2. whose implementation costs nothing - ie has no drawbacks
>    for overall system.
> 
> It was general practice in project so far: if user want some
> feature and it doesn't affect others - let's do it.
> What's changed?

This is another reason to make it be SET TIMEOUT ... because then we
don't have to have this NOWAIT tacked on to every command.  It keeps the
parser and manual pages cleaner, and it is a non-standard extension.

One idea Tom had was to make it only active in a transaction, so you do:
BEGIN WORK;SET TIMEOUT TO 10;UPDATE tab SET col = 3;COMMIT

Tom is concerned people will do the SET and forget to RESET it, causing
all queries to be affected by the timeout.

--  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
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: No printable 7.1 docs?
Next
From: Peter Eisentraut
Date:
Subject: Re: Real/effective user