Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row - Mailing list pgsql-hackers

From David Christensen
Subject Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
Date
Msg-id CAHM0NXg8wWFpJgFyx1q_dVCH8DA9X8yMfwOLbV2DfdwCW8Lrow@mail.gmail.com
Whole thread
In response to Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
List pgsql-hackers
On Thu, Oct 1, 2026 at 9:18 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> > On 1 Oct 2026, at 13:28, Zsolt Parragi <zsolt.parragi@percona.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Corruption Issue: Fix missing tts_tid in ExecForceStoreHeapTuple
Next
From: Jim Jones
Date:
Subject: CREATE TABLE .. LIKE copies comments to an unrelated table