Re: Strange Windows problem, lock_timeout test request

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, 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-02-27 18:38:44
Message-ID: 512E52B4.6000307@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013-02-27 19:07 keltezéssel, Tom Lane írta:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> Tom, can you comment on your thoughts around this notion of an aggregate
>> time constraint for waiting on locks? As mentioned upthread, I like the
>> idea of having an upper-limit on waiting for relation-level locks, but
>> once you're past that, I'm not sure that an aggregate waiting-on-locks
>> is any better than the overall statement-level timeout and it seems
>> somewhat messy, to me anyway.
> I think anything that makes this patch simpler is a good idea. I don't
> like any of the accum_time stuff: it complicates the timeout API
> unreasonably and slows down existing use cases.

Perfect. :-)

> Some other thoughts:
>
> * timeout_reset_base_time() seems like an ugly and unnecessary API wart.
> I don't like the timeout_start state variable at all; if you need
> several timeouts to be scheduled relative to the exact same starting
> point, can't you just do that in a single enable_multiple_timeouts()
> call? And I think the optional TMPARAM_ACCUM action is completely
> unacceptable,

If we get rid of the per-statement variant, there is no need for that either.

> because it supposes that every user of a timeout, now and
> in the future, is okay with having their accumulated time reset at the
> same point. The whole point of having invented this timeout API is to
> serve timeout uses we don't currently foresee, so actions that affect
> every timeout seem pretty undesirable.
>
> * I don't care for changing the API of enable_timeout_after when there
> is in fact not a single caller using the flags argument (probably
> because the only defined flag is too baroque to be useful). If there
> were a use case for the "accum" action it'd be better to have a separate
> API function for it, probably.

This way, enable_timeout_after() wouldn't have this extra argument either.

Thanks for your kind words.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-02-27 19:06:34 Re: Strange Windows problem, lock_timeout test request
Previous Message Tom Lane 2013-02-27 18:36:17 Re: isolation test problem with MSVC (VC2012) / Windows 8