Re: WAIT FOR NO_THROW option could use some documentation

On Thu, Sep 10, 2026 at 9:10 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> Hi Rithvika,
>
> On Tue, Sep 8, 2026 at 11:49 AM Rithvika Devisetti
> <devisettirithvika(at)gmail(dot)com> 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.

I've rebased the patch. Also, I've slightly adjusted the 3rd
paragraph. In v3 it assumes to enumerate the full list of possible
errors. I think it's fragile as this list becomes invalid with every
new possible error. I've reworded it in the way it specifies some of
possible errors.

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

I think nobody can be very sure on the exact usage pattern. The usage
pattern that motivate this feature is "read-your writes" consistency:
after committing something on the primary, read the database at least
containing these changes on replica. What application should do in
the case of timeout or not-in-recovery state we can't exactly know.
It depends on the business logic and the replication cluster
configuration. The point of NO_THROW is that these states may appear
even when application doesn't misuse WAIT commit (like issuing WAIT
while already holding the snapshot). So, it makes sense to let app
distinguish these states without having to parse the error message.

>T he 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 [pgsql-www(at)lists(dot)postgresql(dot)org] 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

I'm going to push this if no objection (in this case I think we can
skip open items as it's going to be resolved anyway).

------
Regards,
Alexander Korotkov
Supabase