Re: timeout value overflow in wait for lsn

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

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