On Thu, Sep 17, 2026 at 6:00 AM Alexander Korotkov <aekorotkov@gmail.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.
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
