2012-07-13 23:51 keltezéssel, Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>> While doing it, I discovered another bug you introduced.
>> enable_timeout_after(..., 0); would set an alarm instead of ignoring it.
>> Try SET deadlock_timeout = 0;
> Hm. I don't think it's a bug for enable_timeout_after(..., 0) to cause
> a timeout ... but we'll have to change the calling code. Thanks for
> catching that.
You're welcome. This caused a segfault in my second patch,
the code didn't expect enable_timeout_after(..., 0);
to set up a timer.
So, the calling code should check for the value and not call
enable_timeout_*() when it shouldn't, right? It's making the code
more obvious for the casual reader, I agree it's better that way.
Will you post a new version with callers checking their *Timeout settings
or commit it with this change? I can then post a new second patch.
Regarding the lock_timeout functionality: the patch can be reduced to
about half of its current size and it would be a lot less intrusive if the
LockAcquire() callers don't need to report the individual object types
and names or OIDs. Do you prefer the verbose ereport()s or a
generic one about "lock timeout triggered" in ProcSleep()?
>> Same for enable_timeout_at(..., fin_time): if fin_time points to the past,
>> it enables a huge timeout
> No, it should cause an immediate interrupt, or at least after 1
> microsecond. Look at TimestampDifference.
Okay.
--
----------------------------------
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/
