Re: Question on error code selection in conflict detection

On Wed, Jun 11, 2025 at 11:05 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Tue, Jun 10, 2025 at 12:14 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Tue, Jun 10, 2025 at 11:39 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Mon, Jun 9, 2025 at 7:14 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > >
> > > > I was reviewing the code for conflict reporting and became curious
> > > > about the choice of ERRCODE_T_R_SERIALIZATION_FAILURE. This error code
> > > > typically signifies a serialization failure within a transaction under
> > > > serializable isolation, so its use here for a different type of
> > > > conflict seems somewhat out of place. I did notice its use in other
> > > > contexts for recovery conflicts in physical replication, which also
> > > > struck me as a bit unusual.
> > > >
> > > > Given these observations, I'm wondering if it would be more
> > > > appropriate to introduce a new, more specific error code for this
> > > > purpose?
> > > >
> > >
> > > Can we instead try to use other suitable existing error codes?
> >
> > Yeah we can try to do that as well.
> >
> > > CT_UPDATE_ORIGIN_DIFFERS, CT_DELETE_ORIGIN_DIFFERS →
> > > ERRCODE_TRIGGERED_DATA_CHANGE_VIOLATION (27000)
> > > These represent cases where the row exists but differs from the
> > > expected state, conceptually similar to a triggered data change
> > > invalidating the operation.
> >
> > Yeah this looks much better than what we already have.
> >
> > > I have also considered using ERRCODE_TRIGGERED_ACTION_EXCEPTION for
> > > the above, but that sounds to be fit for a generic error that occurs
> > > during the execution of a triggered action (e.g., a BEFORE or AFTER
> > > trigger).
> >
> > Right
> >
> > > CT_UPDATE_MISSING, CT_DELETE_MISSING → ERRCODE_NO_DATA_FOUND (02000)
> > > These are straightforward cases where the target row is missing,
> > > aligning well with the standard meaning of 02000.
> >
> > Yeah this looks good.
> >
> > > I don't have good ideas on the cases for physical replication, as
> > > those seem quite different; we can consider those separately.
> >
> > Yeah we can do that separately, maybe I put more thought on that and
> > send my proposal.
> >
> > > Thoughts?
> >
> > Okay I will put more thought about the proposed error code and also
> > see what others have to say and if we have a consensus I can provide
> > the patch.
>
> After reviewing other error codes, these appear to be the most
> relevant in this context.

+1. On digging deep, among existing codes, these are the most relevant ones.

> PFA patch for the same, I will analyze the
> error code in physical replication recovery conflict and propose what
> is relevant there in a separate patch.
>

The patch looks good.

thanks
Shveta