On Mon, Aug 31, 2026 at 6:17 PM Xuneng Zhou <[email protected]> wrote: > > On Mon, Aug 31, 2026 at 10:07 PM cca5507 <[email protected]> wrote: > > > > > --- The divergence > > > Rounding like this does not make a lot of sense to me in the first > > > place, especially when the value rounded down to is zero, which > > > disables the timeout in lots of places. I don't know whether users > > > have ever been surprised by this behavior and why it was designed like > > > this. One reason for this seems to be that the value is small enough > > > to do so. > > > > > > The general GUC doc says: > > > fractional values are rounded to the nearest integer if the parameter > > > is of integer type. > > > If a fractional value is specified with a unit, it will be rounded to > > > a multiple of the next smaller unit if there is one. > > > > > > However, the individual statement_timeout and lock_timeout > > > descriptions do not clearly warn that a nonzero or negative spelling > > > can round to zero and consequently disable the timeout. They only > > > state that zero disables it. > > > > > > I am wondering whether the timeout in WAIT FOR needs to take a > > > different path since it is not constrained with backward > > > compatibility. > > > > How about just keeping it consistent with GUC: use parse_int() and > > error out if timeout < 0. I didn't see users complaining about this > > behavior. > > TBH, I am not a fan of this workaround unless we deal with the > reported GUC issue later. The strange behaviors reported earlier seems > relatively hard to hit since it requires relatively uncommon input and > it is also not that easy to notice even if it is hit. But the > operational consequence and the scope of affected GUCs seems > non-trivial to me. That said, I don't have enough concentrated time to > dig into the issue, figure out a proper fix and write it down for now, > since I am on a vacation.
I would prefer using parse_int() here. It does lead to some slightly surprising cases (for instance '-0.4ms' converts to 0, which means waiting forever), including the case I raised earlier in this thread. But existing integer GUC parameters such as statement_timeout have been behaving that way, so I don't think it would be a problem in practice. And if we fix the common parsing infrastructure so that it doesn't produce such surprising results, that would fix both places at once. Using parse_int() also addresses the reported overflow at its root, since the value is then capped at INT_MAX milliseconds, which is all that WaitLatch() accepts anyway. As for the currently proposed idea of adding our own checks and rounding, while it would be flexible enough to deal with corner cases that parse_int() and parse_real() don't handle today, I think the GUC side would then have to be fixed as well, and PG19 is not the right time to work on that. > Attached file is a response from Sol > regarding the anomaly which somewhat makes sense to me. It would be > helpful to hear Sawada-san and Alexander's thoughts on it. Also CCed > the members of RMT. FYI I don't think attaching an LLM response as a PDF is a good way to bring material to this list. A most part of it is not about the unit conversion at all, but advice to you about how to revise your report and how to frame the argument here. For instance one section is headed "This changes how I would revise your report", and another closes by noting "makes the proposal much harder to object to". That is odd material to send to the people on this thread who are working on this problem, and it leaves the readers to figure out which parts are claims about PostgreSQL and which are not, and to verify the contents. I'd rather see the parts you have verified yourself, stated in your own words and in plain text. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
