Re: WAIT FOR NO_THROW option could use some documentation

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Kiran Kaki <itskkpg(at)gmail(dot)com>, Rithvika Devisetti <devisettirithvika(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAIT FOR NO_THROW option could use some documentation
Date: 2026-09-04 09:38:39
Message-ID: CABPTF7ULLsUHPP969idsEFHbc4z5wPmHxTGfJed_FMw3RV7arA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Satya,

On Fri, Sep 4, 2026 at 7:00 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Thu, Sep 3, 2026 at 1:39 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>
>> On 03.09.26 17:21, SATYANARAYANA NARLAPURAM wrote:
>> > 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"?
>>
>> Maybe that's what it is meant for, but that seems separate from the
>> status reporting mechanism. It could also send an error message to the
>> client but not abort the transaction on the server.
>
>
> Curious, Is there an existing precedent for this in the core where we send an error
> but not abort a transaction on the server? Parsing error messages is painful compared
> to reading the result set it seems.

I asked Sol to investigate this, and it said it did not find one.

> Additionally, I see the information passed to the client when an error is thrown much richer
> than a row returned like timeout. Perhaps if we decide to support NO_THROW should
> we consider adding a current replay LSN as well?

I think this depends on how applications are expected to use the
result. If the primary use of it is states for application control
flow, then the brevity seems good to me. For extended diagnostic or
monitoring purposes, adding a companioning LSN might make sense.
Humans might prefer richer messages if they would look at it, but it
might not necessarily be the interface an application should have to
parse.I don't know how users would actually use it.

> postgres=# WAIT FOR LSN '0/306EE20' WITH (TIMEOUT '0.1s');
> ERROR: timed out while waiting for target LSN 0/306EE20 to be replayed; current replay LSN 0/306EA60
>
> postgres=# WAIT FOR LSN '0/306EE20' WITH (TIMEOUT '100ms', NO_THROW);
> status
> ---------
> timeout
> (1 row)
>
> Thanks,
> Satya

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2026-09-04 09:50:50 Re: Further cleanup related to statistics import support in postgres_fdw
Previous Message Tender Wang 2026-09-04 09:30:00 Re: Assert failure in try_nestloop_path()