On Thu, Sep 3, 2026 at 11:21 PM SATYANARAYANA NARLAPURAM < [email protected]> wrote: > > 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 for the suggestion. I guess that this is the main differentiater from other alternatives. As Robert and you pointed out earlier -- no_throw cannot suppress all errors. I think it's true. Then the first part of the para may be too broad -- it cannot protect everything -- some errors still abort txn. I am also wondering whether we need to emphasize "why no_throw is genuinely needed" over "when/how to use it". Yeah, there are alternatives to achieve almost the same thing(maybe less graceful) like riding a horse or car can both go to a place (may not be a good analogy). Do users really care that much why a car is better than a horse in what aspects and why do they want a car even they have a horse? If we offer them an option, we might want to tell them when/how to use it just like a car manual won't have much material about why it is unreplaceble from and superior to its peers. If that make sense, I found the version that Kiran suggested to be useful. Here's a edited version on that: Use NO_THROW when timeout or not in recovery is an expected result that the application intends to handle, for example by retrying the wait, reporting replication delay, or choosing another server for a subsequent operation. The command then returns the result as a status, which the application must check before assuming that the target LSN was reached. Omit NO_THROW when the application must not proceed unless the target LSN is reached, so that an unsuccessful wait stops normal execution with an error. Returning a status also leaves an explicit transaction usable; without NO_THROW, the corresponding error requires rollback of the transaction or to a savepoint before further commands can be issued. NO_THROW changes only how timeout and not in recovery are reported; other errors are still raised. It does not limit the duration of the wait; specify TIMEOUT for that purpose. WDT? --- Regards, Xuneng Zhou HighGo Software Co., Ltd.
