Re: Question on error code selection in conflict detection
От | Dilip Kumar |
---|---|
Тема | Re: Question on error code selection in conflict detection |
Дата | |
Msg-id | CAFiTN-u_Gp66efZ8G4r3+oyq1M84_HeZF+2oXLSO+cFWgJgiZA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question on error code selection in conflict detection (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
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. -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: