Re: WAIT FOR NO_THROW option could use some documentation

On Thu, Sep 17, 2026 at 6:41 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> On Thu, Sep 17, 2026 at 6:00 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> > 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.
>
> Make sense.
>
> > > 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.
>
> Thanks for the explanation.
>
> > 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).
>
> LGTM.

Thank you, pushed.

------
Regards,
Alexander Korotkov
Supabase