From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Question on error code selection in conflict detection |
Date: | 2025-06-10 06:44:52 |
Message-ID: | CAFiTN-u_Gp66efZ8G4r3+oyq1M84_HeZF+2oXLSO+cFWgJgiZA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 10, 2025 at 11:39 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Jun 9, 2025 at 7:14 PM Dilip Kumar <dilipbalaut(at)gmail(dot)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.
--
Regards,
Dilip Kumar
Google
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-06-10 06:59:29 | pg_dump/pg_dumpall help synopses and terminology |
Previous Message | Dilip Kumar | 2025-06-10 06:44:40 | Re: Question on error code selection in conflict detection |