Re: timeout value overflow in wait for lsn

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.

> 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