Hi On Mon, Aug 31, 2026 at 11:28 PM Xuneng Zhou <[email protected]> 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 .
