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. -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
