On Thu, Sep 3, 2026 at 4:20 PM Robert Haas <[email protected]> wrote:
> On Thu, Sep 3, 2026 at 4: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. > > I think sending an error without aborting the transaction on the > server would invite too much confusion. But I also wonder if the > documentation's claim that this option will just cause the server to > categorically not throw errors can really be correct. In most places > where we have an error-suppression facility of some kind, it's much > more narrowly scoped. > Agree with Robert on this. I would say the error suppression is narrow here as well. When an incorrect mode or LSN is provided, it throws an error even with the NO_THROW option. postgres=# WAIT FOR LSN '0/306EEk0' WITH (TIMEOUT '100ms', NO_THROW, MODE primary_flush); ERROR: invalid input syntax for type pg_lsn: "0/306EEk0" postgres=# WAIT FOR LSN '0/306EE0' WITH (TIMEOUT '100ms', NO_THROW, MODE primary_flush2); ERROR: unrecognized value for WAIT option "mode": "primary_flush2"
