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

From Henryk Szal
Subject Re: timeout on lock feature
Date
Msg-id 9bgvb2$12uf$1@news.tht.net
Whole thread Raw
In response to Re: timeout on lock feature  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: timeout on lock feature  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
YES, this feature should affect ALL locks.
'Timeout on lock' parameter says to server "I CAN'T WAIT WITH THIS
TRANSACTION TOO LONG BECAUSE OF (ANY) LOCK",
so if my process is in conflict with another (system or user) process, then
i want to abort
my transaction. Somebody can set timeout to bigger value (minutes, for
example). In my OLTP applications
i set this value to 10 sec. because i have a lot of short transactions
generated by operators.
LOCK TABLE is deficient because i need not wait also on some technical locks
(if this locks blocks me too long!).


Tom Lane wrote in message <4547.987180295@sss.pgh.pa.us>...
>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?
>
>A variant of LOCK TABLE that explicitly requests a timeout might make
>sense, though.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://www.postgresql.org/search.mpl




pgsql-hackers by date:

Previous
From: Lehel Gyuro
Date:
Subject: plpgsql problem
Next
From: "Víctor R. Ruiz"
Date:
Subject: Handling error messages