Hi, On Thu, Sep 3, 2026 at 1:10 AM Xuneng Zhou <[email protected]> wrote:
> Hi Peter, > > On Thu, Sep 3, 2026 at 4:05 AM Peter Eisentraut <[email protected]> > 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
