Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row

From: David Christensen <david+pg(at)pgguru(dot)net>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
Date: 2026-10-01 14:31:25
Message-ID: CAHM0NXg8wWFpJgFyx1q_dVCH8DA9X8yMfwOLbV2DfdwCW8Lrow@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 1, 2026 at 9:18 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> > On 1 Oct 2026, at 13:28, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> >
> > Maybe we should open a bug report to pg_lake about this? Even if we
> > allow for this here, the documentation still requires es_snapshot to
> > be set.
>
> It's the cost of breaking old pg_lake users and possible unknown buggy users
> against cost of extra runtime check for all others.
>
> I don't have personal preferences in this choice. But I suspect that project
> policy is that Postgres works. Without much surprises.

One of the pg_lake maintainers here; so the basic issue is that we
didn't populate the es_snapshot field in the Estate, so just setting
that to the active current snapshot before calling
ExecCheckIndexConstraints() is the fix?

TL;DR; this is only an 18/19 issue, or it needs backported all the way down?

Thanks,.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2026-10-01 14:35:15 CREATE TABLE .. LIKE copies comments to an unrelated table
Previous Message Andres Freund 2026-10-01 14:16:05 Re: [PATCH] Corruption Issue: Fix missing tts_tid in ExecForceStoreHeapTuple