From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Hari Babu <haribabu(dot)kommi(at)huawei(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>, Ants Aasma <ants(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Amit kapila <amit(dot)kapila(at)huawei(dot)com> |
Subject: | Re: Strange Windows problem, lock_timeout test request |
Date: | 2013-03-06 18:53:49 |
Message-ID: | 19702.1362596029@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> It's still entirely possible to get 99% done and then hit that last
>> tuple that you need a lock on and just tip over the lock_timeout_stmt
>> limit due to prior waiting and ending up wasting a bunch of work, hence
>> why I'm not entirely sure that this is that much better than
>> statement_timeout.
> I tend to agree that this should be based on the length of any
> individual lock wait, not the cumulative duration of lock waits.
> Otherwise, it seems like it'll be very hard to set this to a
> meaningful value. For example, if you set this to 1 minute, and that
> means the length of any single wait, then you basically know that
> it'll only kick in if there is some other, long-running transaction
> that's holding the lock. But if it means the cumulative length of all
> waits, it's not so clear, because now you might also have this kick in
> if you wait for 100ms on 600 different occasions. In other words,
> complex queries that lock or update many tuples may get killed even if
> they never wait very long at all for any single lock. That seems like
> it will be almost indistinguishable from random, unprincipled query
> cancellations.
Yeah. I'm also unconvinced that there's really much use-case territory
here that statement_timeout doesn't cover well enough. To have a case
that statement-level lock timeout covers and statement_timeout doesn't,
you need to suppose that you know how long the query can realistically
wait for all locks together, but *not* how long it's going to run in the
absence of lock delays. That seems a bit far-fetched, particularly when
thinking of row-level locks, whose cumulative timeout would presumably
need to scale with the number of rows the query will visit.
If statement-level lock timeouts were cheap to add, that would be one
thing; but given that they're complicating the code materially, I think
we need a more convincing argument for them.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2013-03-06 18:58:06 | Re: Strange Windows problem, lock_timeout test request |
Previous Message | Robert Haas | 2013-03-06 18:34:53 | Re: Enabling Checksums |