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