Re: ON CONFLICT DO SELECT (take 3)

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Viktor Holmberg <v(at)viktorh(dot)net>, pgsql-hackers(at)postgresql(dot)org, Marko Tiikkaja <marko(at)joh(dot)to>, Andreas Karlsson <andreas(at)proxel(dot)se>
Subject: Re: ON CONFLICT DO SELECT (take 3)
Date: 2025-11-25 10:04:36
Message-ID: CAEZATCXboUd3HTOph4Ae5kJ=My_Vc2t2re5TuuunRBkOW55Lgw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 25 Nov 2025 at 08:33, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> v16-0002: using INJECTION_POINT to test the case when
> ExecOnConflictSelect->ExecOnConflictLockRow returns false.
>

In general, having more tests is a good thing, but I think this is
setting a higher bar for the ON CONFLICT DO SELECT than existing code,
such as ON CONFLICT DO UPDATE. ExecOnConflictUpdate() also uses
ExecOnConflictLockRow() in the same way, and doesn't have such a test,
and there are other lock-and-retry paths in the executor not tested in
this way.

IMO, using injection points for testing a wider variety of possible
race conditions in the executor should be considered as a separate
patch.

Regards,
Dean

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-11-25 10:06:09 Re: Extended Statistics set/restore/clear functions.
Previous Message Heikki Linnakangas 2025-11-25 09:57:39 Re: IPC/MultixactCreation on the Standby server