From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Alex Aktsipetrov <alex(dot)akts(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks |
Date: | 2019-07-09 11:47:28 |
Message-ID: | CA+hUKG+3YYDHn4VzEh9hxbWta3s7dYMQk6bODbz6bYJwpNV=FQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Jul 9, 2019 at 1:13 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-07-09 14:39:55 | Re: BUG #15901: Tablespace showing as null in psql and pgadmin |
Previous Message | PG Bug reporting form | 2019-07-09 11:43:56 | BUG #15902: pgAdmin generates faulty SQL |