Hi Rithvika, On Tue, Sep 8, 2026 at 11:49 AM Rithvika Devisetti <[email protected]> wrote: > > Thank you everyone for the suggestions. > v3 attached, folding in the remaining points. > > The description now says the command "reports these outcomes as a > status string instead of raising an error", tying it to the timeout and > promotion cases named just above rather than claiming suppression > generally. > > The option entry uses the consolidated wording from earlier in the > thread, and its last paragraph now names what still errors: invalid > inputs (Satya's malformed-LSN and unrecognized-mode examples), and > requesting primary_flush during recovery, which is rejected before the > wait begins, per Xuneng's note.
Personally, v3 LGTM. That said, I am not familiar with and very sure about the exact use of the option in the application side. It would be helpful to hear other hackers' opinions on it. The patch seems to deserve a mention in the open items page[1]. Can you add it, if you have the access? I emailed the administrator [[email protected]] some time ago, but got no response back. And again, please place your response *after* the snippet of the email you want to reply to like this comment from me did. It protects the logic flow of reading email. [1] https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items > On Sat, Sep 5, 2026 at 12:23 AM Xuneng Zhou <[email protected]> wrote: >> >> >> >> On Fri, Sep 4, 2026 at 8:26 AM SATYANARAYANA NARLAPURAM >> <[email protected]> wrote: >> > >> > >> > >> > 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. >> >> Yeah, I also think Robert is right for not claiming it absolutely. >> >> "If NO_THROW is specified, the command returns a status string instead of >> throwing errors." >> >> We may need to soften this line. >> >> > 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" >> >> Thanks for testing this. I agree that the behavior is not aligned with the >> description of doc. The behavior itself seems fine to me, what we need to >> change is the doc. These errors are not supposed to be suppressed because >> they are not valid inputs in the first place. Another one error needs >> consideration is primary_flush waiting in standby. Currently, we prevent >> this use by erroring out before entering the wait, hence no_throw option >> cannot suppress it. I think this behavior is fine. To suppressithat error >> implies that we want a new return status like 'in recovery' after valid >> waiting. However, that needs seems not true because we don't expect a >> primary being demoted to a standby. We might still need extra description >> for it. -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
