On Thu, Sep 17, 2026 at 6:41 AM Xuneng Zhou <[email protected]> wrote: > On Thu, Sep 17, 2026 at 6:00 AM Alexander Korotkov <[email protected]> > 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
