ion are in conflict, then
both will be executed (second 3 sec. later).
Ian Lance Taylor wrote in message ...
>"Henryk Szal" <[EMAIL PROTECTED]> writes:
>
>> YES, I DO! My transaction can't wait.
>> If parser on planner is blocked, then i want to abort my transa
This option will be OPTIONAL.
Tom Lane wrote in message <[EMAIL PROTECTED]>...
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Added to TODO:
>> * Add SET parameter to timeout if waiting for lock too long
>
>I repeat my strong objection to any global (ie, affecting all locks)
>timeout. Such a "fea
Hi,
for 10 years i develop DB application using 'timeout on lock' feature
(Informix,Ingres,AdabasD,RDB,...).
I think about migrate with this application to postgresql, and with this
feature i don't need to modify my ready to run code specially for
postgresql. This feature guard me against blockin
Tom Lane wrote in message <[EMAIL PROTECTED]>...
>Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I was thinking SET because UPDATE does an auto-lock.
>
>Not to mention a ton of implicit locks acquired on various system tables
>during parsing/planning. You really want auto timeout on all of those?
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
Hi,
I implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in
the first one. In real OLTP application second process can't wait too long.
Afte
Hi,
i implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in the first one.
In real OLTP application second process can't wait too long. Afte
