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

From Zsolt Parragi
Subject Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
Date
Msg-id CAN4CZFO5Yk_Yv9Vv0N_kUuPYH_X3TLw52a2nUCeTzqqaNFtBTw@mail.gmail.com
Whole thread
In response to Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row  (David Christensen <david+pg@pgguru.net>)
Responses Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row
List pgsql-hackers
> 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?

Yes.

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

If we go with the second version of the fix, which is more defensive,
there will be no issues in any branches even if you pg_lake doesn't
set it.
If we go with only the first version that fixes logical replication in
18/19, the problematic code will be there on all branches, so 14+.

But regardless to this, CreateExecutorState documents on all branches
that callers are expected to set es_snapshot:

    /*
     * Initialize all fields of the Executor State structure
     */
    estate->es_direction = ForwardScanDirection;
    estate->es_snapshot = InvalidSnapshot;    /* caller must initialize this */
    estate->es_crosscheck_snapshot = InvalidSnapshot;    /* no crosscheck */

So I think it would be good practice to set it, independently to this bug.



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: serializable anomaly - duplicate primary keys
Next
From: David Christensen
Date:
Subject: Re: SSI: ON CONFLICT DO SELECT takes no predicate lock on the returned row