| 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 |
| 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 |