Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Alex Aktsipetrov <alex.akts@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2019-07-09T11:47:28Z
Lists: pgsql-bugs
On Tue, Jul 9, 2019 at 1:13 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > Hmm, I wonder if EPQ might be involved in bug report #15720 (version 11.2):
> >
> > https://www.postgresql.org/message-id/flat/15720-38c2b29e5d720187%40postgresql.org
>
> I think it's highly likely that bug #15720 was a case of this bug and
> would be fixed by this patch.  Alex's repro doesn't work on 11 though,
> because EPQ is not entered at all.  Which raises the question: why do
> we need to enter EPQ after commit ad0bda5d on 12/master, for a row
> that hasn't been updated by anyone else?

Explanation: since ad0bda5d24ea, ExecLockRows() always calls
EvalPlanQualBegin() which initialises the plan state, and in this case
ExecInitNamedTuplestoreScan() errors out due to the bug.  Before, you
needed the right concurrency scenario (epq_needed) before we did that,
as the reporter of bug #15720 discovered.

I'm planning to commit that patch tomorrow.

-- 
Thomas Munro
https://enterprisedb.com



Commits

  1. Pass QueryEnvironment down to EvalPlanQual's EState.

  2. Store tuples for EvalPlanQual in slots, rather than as HeapTuples.