Re: WAIT FOR NO_THROW option could use some documentation

On Thu, Sep 3, 2026 at 11:21 PM SATYANARAYANA NARLAPURAM <
satyanarlapuram(at)gmail(dot)com> wrote:
>
> 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 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.