Hi Satya, On Fri, Sep 4, 2026 at 7:00 AM SATYANARAYANA NARLAPURAM <[email protected]> wrote: > > Hi, > > On Thu, Sep 3, 2026 at 1:39 PM Peter Eisentraut <[email protected]> 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.
