Re: AW: timeout on lock feature

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: AW: timeout on lock feature
Дата
Msg-id 200104181858.f3IIwgW14130@candle.pha.pa.us
обсуждение исходный текст
Ответ на RE: AW: timeout on lock feature  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: No printable 7.1 docs?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Real/effective user