Re: Question on error code selection in conflict detection

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(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:09:08
Message-ID: CAA4eK1KXty6ZLwKrwE05riN0igG=_8hX+h+RbQ3sunrtP4FyzA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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.

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).

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.

I don't have good ideas on the cases for physical replication, as
those seem quite different; we can consider those separately.

Thoughts?

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2025-06-10 06:25:34 RE: Conflict detection for update_deleted in logical replication
Previous Message Mihail Nikalayeu 2025-06-10 06:00:00 Re: [BUG?] check_exclusion_or_unique_constraint false negative