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

From Dean Rasheed
Subject Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
Date
Msg-id CAEZATCXiHxh-UZFj5QeStAjkoof+=DqYgaOvdQGE2DJt2nbQ_A@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 Wed, 23 Sept 2026 at 12:22, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> The snapshot change looks correct to me.

Hmm, I'm not so sure.

I'm thinking now that making ExecCheckIndexConstraints() require
estate->es_snapshot was actually an unintended change of the kind that
probably wasn't safe for back-patching, because it might affect
extension code.

Perhaps, instead, we should make it only do the re-fetch if
estate->es_snapshot is not InvalidSnapshot. For logical replication,
it actually seems unnecessary anyway, since it's only replaying an
update that has already been successfully committed by the publisher.

I wonder if it was actually intentional that logical replication
workers don't set es_snapshot on the EState, since they don't use it
to scan tables, so estate->es_snapshot is not needed.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [PATCH] Two remaining shmem attachment issues in single-user mode
Next
From: Andrey Borodin
Date:
Subject: Re: Orphaned Files in PostgreSQL