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