Re: WAIT FOR NO_THROW option could use some documentation

Hi,

On Thu, Sep 3, 2026 at 1:10 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:

> Hi Peter,
>
> On Thu, Sep 3, 2026 at 4:05 AM Peter Eisentraut <peter(at)eisentraut(dot)org>
> wrote:
> >
> > On 01.09.26 08:28, Xuneng Zhou wrote:
> > > 'NO_THROW' was added to make those statuses available for ordinary
> > > application control flow. Without it, 'timeout' and 'not in recovery'
> > > are raised as SQL errors. With it, they are returned as status values,
> > > allowing the application to retry, report replication lag, refresh its
> > > routing information, or direct a subsequent read to the primary. In
> > > that sense, 'NO_THROW' selects how these expected wait outcomes are
> > > reported: through the error channel or through the result row.
> >
> > This just explains the technical distinction, not why it's needed.
> > Applications or client frameworks could just as well inspect an error
> > return with for example an appropriate error code. That's what they'd d
> > for any other command.
>
> That's interesting. I was unaware of the use of error codes as the
> states of application logical control flow. But that use seems not
> elegant to me or maybe I misunderstood its usage.
>
> ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE
> ERRCODE_QUERY_CANCELED
>
> These error codes are overloaded in terms of meaning and the
> conditions lead to each. They are not tailed for the return states of
> WAIT FOR. If I was a user, I would be less happy to figure out what
> they mean and what they are represented for.
>
> errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> errmsg("recovery is not in progress"),
>
> errcode + errmsg together seems to be a more sensible state, but it
> would require extra parsing effort.
>

> But this alone seems not warrant a standalone option. The direction
> that Rithvika put earlier now makes more sense to me. But I would
> suggest adjusting its expression and adding examples. I'll reply later
> while I get more time.
>

Maybe something along these lines - "NO_THROW option safely prevents the
database
from aborting an active transaction, allowing subsequent queries within the
transaction
to proceed without losing prior work"?

Thanks,
Satya