> "Henryk Szal" <[EMAIL PROTECTED]> writes:
> > 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",
>
> It still seems to me that what such an application wants is not a lock
> timeout
"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 transaction.
What are your actual timing constraints? Is the constraint ``no
database table access may take longer than 10 seconds?'' Or is it
``no datab
"Henryk Szal" <[EMAIL PROTECTED]> writes:
> 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",
It still seems to me that what such an application wants is not a lock
timeout at all, but an
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
