Re: Strange Windows problem, lock_timeout test request

Boszormenyi Zoltan <zb@cybertec.at>

From: Boszormenyi Zoltan <zb@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Hari Babu <haribabu.kommi@huawei.com>, 'Craig Ringer' <craig@2ndQuadrant.com>, 'Hans-Jürgen Schönig' <hs@cybertec.at>, 'Ants Aasma' <ants@cybertec.at>, 'PostgreSQL Hackers' <pgsql-hackers@postgresql.org>, 'Amit kapila' <amit.kapila@huawei.com>
Date: 2013-02-27T18:38:44Z
Lists: pgsql-hackers
2013-02-27 19:07 keltezéssel, Tom Lane írta:
> Stephen Frost <sfrost@snowman.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/