Re: WAIT FOR NO_THROW option could use some documentation

Hi

On Mon, Aug 31, 2026 at 11:28 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> I am not the author who added the option. So the following are just
> some random guesses for the motivation of introducing it after doing
> some archeological works[1] [2] [3] [4].
>
> Different return statuses were introduced so that an application could
> determine why a wait ended. Reaching the target LSN, reaching the
> timeout, and discovering that the server is no longer in recovery are
> operationally different results. Reporting them as 'success',
> 'timeout', and 'not in recovery' gives clients a stable,
> machine-readable interface instead of forcing them to parse error
> messages, which may also be localized.
>
> '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.
>
> Avoiding an aborted transaction is a secondary benefit. When
> 'NO_THROW' returns a status, an explicit transaction remains usable;
> otherwise, the application must roll back the transaction or to a
> savepoint. But transaction preservation was not the principal
> motivation. Without distinct return statuses, merely suppressing
> errors would be of little use because the application would not know
> whether the target LSN had actually been reached.
>
> [This piece is written and revised by Sol from my instructions. I
> don't have enough time to write a version of mine.]

Thanks for looking into the history and clarifying the original
motivation. The distinction between returning the wait outcome through
a result row and keeping the transaction usable is helpful. I agree
that the documentation should emphasize machine-readable statuses and
application control flow as the primary motivation, while mentioning
transaction preservation as a secondary benefit.

Regards,
Kiran Kaki
.