From: | "Henryk Szal" <szal(at)doctorq(dot)com(dot)pl> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timeout on lock feature |
Date: | 2001-04-17 09:09:22 |
Message-ID: | 9bh0q7$136l$1@news.tht.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote in message <4982(dot)987184866(at)sss(dot)pgh(dot)pa(dot)us>...
>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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?
>I sure don't.
*****************************************
YES, I DO! My transaction can't wait.
If parser on planner is blocked, then i want to abort my transaction.
*****************************************
>
>The appropriate way to do this given a LOCK TABLE option would be like
>
> BEGIN;
> LOCK TABLE foo IN ROW EXCLUSIVE MODE WITH TIMEOUT n;
> UPDATE foo SET ...;
> COMMIT;
>
*****************************************
With this solution, some server processes can block me!
*****************************************
>which restricts the scope of the timeout behavior to just the specific
>lock that the user is thinking of, and doesn't risk breaking fundamental
>system operations.
>
> regards, tom lane
*****************************************
This is real problem, but i think other postgres modules are ready for my
solution
(because it is extension to deadlock detection mechanism)
*****************************************
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://www.postgresql.org/search.mpl
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 2001-04-17 10:11:37 | Re: broken web server? |
Previous Message | Gavin Sherry | 2001-04-17 08:58:36 | Foreign key checks/referential integrity. |