Re: WAIT FOR NO_THROW option could use some documentation

From: Rithvika Devisetti <devisettirithvika(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAIT FOR NO_THROW option could use some documentation
Date: 2026-08-31 18:39:11
Message-ID: CA+HR5vjVMUE6d7zjPEht9a4rft9AOtik30PR4m1JBu3ghxHTfw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2026-08-31 at 07:47 +0200, Peter Eisentraut wrote:
> I don't find any documentation for the WAIT FOR NO_THROW option other
> than a few short sentences in the man page about what it does
> technically. But I don't find anything about why one would want to use
> it (or not).

Hello,

Attached is a patch.

The reason I settled on is that the difference is transactional. The
error raised without NO_THROW aborts the current transaction, so a
caller that treats a timeout as recoverable (retry, fall back to the
primary, report the delay) has to roll back first and discard whatever
else that transaction had done. With NO_THROW the session is
unaffected and the caller can branch on the returned status. I
confirmed this: a timeout inside a transaction block leaves it aborted,
while the same wait with NO_THROW leaves the session usable.

Regards,
Rithvika Devisetti

On Mon, Aug 31, 2026 at 7:47 AM Peter Eisentraut <peter(at)eisentraut(dot)org>
wrote:

> I don't find any documentation for the WAIT FOR NO_THROW option other
> than a few short sentences in the man page about what it does
> technically. But I don't find anything about why one would want to use
> it (or not). I suspect this option was added with some particular
> client control flow in mind, but I think this needs to be explained
> somewhere.
>
>
>

Attachment Content-Type Size
0001-doc-Explain-when-to-use-the-WAIT-FOR-NO_THROW-option.patch application/octet-stream 2.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alberto Piai 2026-08-31 18:41:33 Re: Adding a stored generated column without long-lived locks
Previous Message Bharath Rupireddy 2026-08-31 18:14:03 Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start