| 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-11 05:35:30 |
| Message-ID: | CAFiTN-vnR8M5xON+FVkUrc_9Z+j7p4UoR6=JMji_37SXd=c47g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 10, 2025 at 12:14 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> 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.
After reviewing other error codes, these appear to be the most
relevant in this context. 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.
--
Regards,
Dilip Kumar
Google
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Improve-error-codes-for-logical-replication-conflict.patch | application/octet-stream | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Evgeny Voropaev | 2025-06-11 06:00:01 | Re: Add 64-bit XIDs into PostgreSQL 15 |
| Previous Message | Yugo Nagata | 2025-06-11 05:03:01 | Re: Extend ALTER DEFAULT PRIVILEGES for large objects |