Re: timeout value overflow in wait for lsn

On Wed, Sep 2, 2026 at 5:09 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Mon, Aug 31, 2026 at 6:17 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> >
> > On Mon, Aug 31, 2026 at 10:07 PM cca5507 <cca5507(at)qq(dot)com> 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.

Agree. Maybe it is not a good time to do so for v19, which means that
the timeout in wait for could be a new victim of that. I still think
that it needs to be fixed in HEAD. The current generation of LLM keeps
finding embarrassing bugs as we can see in the pre-release season.
This is one example of that. At first, it seems trivial to me.
However, it turns out to not be the case as I looked into it. Fixing
bugs is not fun and I don't like to do it all the time. But some bugs
left unreported and unfixed would certainly surprise and disappoint
users one day. I guess the number and the frequency of bugs reporting
to the mailing list could only be used as one aspect of criteria for
judging whether the bug needs to be fixed or not, given lots of users
are not accustomed to the working style of mailing lists and are not
able to write decent reports in English, which demotivate them to
report, or simply don't know the existence of the channel.

> > 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.

Also agree. I didn't have a laptop at hand and enough concentrated
time at that time. I could've done better on myself later but thought
I needed to report it early at a faster pace. The conversation
happened on my mobile phone. I don't like the tone and expression it
used, which I ask explicitly not to do so in Codex on the computer.
Sorry if this seems a disrespect of your time.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.