pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
9+ messages / 6 participants
[nested] [flat]
* BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
@ 2019-07-08 22:22 PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:32 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Александр Акципетров <alex.akts@gmail.com>
2019-07-08 23:39 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Alex Aktsipetrov <alex.akts@gmail.com>
0 siblings, 2 replies; 9+ messages in thread
From: PG Bug reporting form @ 2019-07-08 22:22 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: alex.akts@gmail.com
The following bug has been logged on the website:
Bug reference: 15900
Logged by: Alex Aktsipetrov
Email address: alex.akts@gmail.com
PostgreSQL version: 12beta2
Operating system: Ubuntu 16.04
Description:
SELECT FOR UPDATE query that references a transition table in AFTER
INSERT/UPDATE triggers produces an unexpected error. The same query with FOR
UPDATE omitted finishes without any error, which is my expectation for the
original one as well. AFTER DELETE triggers were not tested.
For example, the following query:
create table testtr (a int, b text);
create function testtr_trigger() returns trigger language plpgsql as
$$begin
perform(
select array_agg(a) from
(select testtr.a from testtr join new_table on testtr.a = new_table.a
for update)
as tmp
);
return new;
end$$;
create trigger testtr_trigger
after insert on testtr
referencing new table as new_table
for each statement execute procedure testtr_trigger();
insert into testtr values (1, 'one'), (2, 'two');
produces the following error:
ERROR: executor could not find named tuplestore "new_table"
CONTEXT: SQL statement "SELECT (
select array_agg(a) from
(select testtr.a from testtr join new_table on testtr.a = new_table.a
for update)
as tmp
)"
I think the issue was introduced in ad0bda5d24ea2bcc72b5e50020e3c79bab10836b
as the query finishes successfully in its ancestor.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
@ 2019-07-08 23:32 ` Александр Акципетров <alex.akts@gmail.com>
1 sibling, 0 replies; 9+ messages in thread
From: Александр Акципетров @ 2019-07-08 23:32 UTC (permalink / raw)
To: Александр Акципетров <alex.akts@gmail.com>; pgsql-bugs@lists.postgresql.org
On Tue, 9 Jul 2019 at 01:22, PG Bug reporting form <noreply@postgresql.org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15900
> Logged by: Alex Aktsipetrov
> Email address: alex.akts@gmail.com
> PostgreSQL version: 12beta2
> Operating system: Ubuntu 16.04
> Description:
>
> SELECT FOR UPDATE query that references a transition table in AFTER
> INSERT/UPDATE triggers produces an unexpected error. The same query with
> FOR
> UPDATE omitted finishes without any error, which is my expectation for the
> original one as well. AFTER DELETE triggers were not tested.
>
> For example, the following query:
>
> create table testtr (a int, b text);
>
> create function testtr_trigger() returns trigger language plpgsql
> as
> $$begin
> perform(
> select array_agg(a) from
> (select testtr.a from testtr join new_table on testtr.a =
> new_table.a
> for update)
> as tmp
> );
> return new;
> end$$;
>
> create trigger testtr_trigger
> after insert on testtr
> referencing new table as new_table
> for each statement execute procedure testtr_trigger();
>
> insert into testtr values (1, 'one'), (2, 'two');
>
> produces the following error:
>
> ERROR: executor could not find named tuplestore "new_table"
> CONTEXT: SQL statement "SELECT (
> select array_agg(a) from
> (select testtr.a from testtr join new_table on testtr.a =
> new_table.a
> for update)
> as tmp
> )"
>
> I think the issue was introduced in
> ad0bda5d24ea2bcc72b5e50020e3c79bab10836b
> as the query finishes successfully in its ancestor.
>
>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
@ 2019-07-08 23:39 ` Alex Aktsipetrov <alex.akts@gmail.com>
2019-07-08 23:49 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
1 sibling, 1 reply; 9+ messages in thread
From: Alex Aktsipetrov @ 2019-07-08 23:39 UTC (permalink / raw)
To: Александр Акципетров <alex.akts@gmail.com>; pgsql-bugs@lists.postgresql.org
Sorry, the previous email was a fat finger error.
Attaching the patch that fixes the issue, although I am not familiar with
the codebase to be sure that it is the right idea.
Attachments:
[text/x-patch] trigger_select_for_update.patch (495B, ../../CALPsoAL2x_C=hMK0M459rijUVcrchjVT6k7vFduP47iCMRh77Q@mail.gmail.com/3-trigger_select_for_update.patch)
download | inline diff:
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 27f0345..cf5585f 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -2874,6 +2874,8 @@ EvalPlanQualStart(EPQState *epqstate, EState *parentestate, Plan *planTree)
}
}
+ estate->es_queryEnv = parentestate->es_queryEnv;
+
/*
* Each EState must have its own es_epqScanDone state, but if we have
* nested EPQ checks they should share es_epqTupleSlot arrays. This
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:39 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Alex Aktsipetrov <alex.akts@gmail.com>
@ 2019-07-08 23:49 ` Thomas Munro <thomas.munro@gmail.com>
2019-07-09 01:13 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Thomas Munro @ 2019-07-08 23:49 UTC (permalink / raw)
To: Alex Aktsipetrov <alex.akts@gmail.com>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Andres Freund <andres@anarazel.de>
On Tue, Jul 9, 2019 at 11:39 AM Alex Aktsipetrov <alex.akts@gmail.com> wrote:
> Attaching the patch that fixes the issue, although I am not familiar with the codebase to be sure that it is the right idea.
Thanks for the report and the proposed fix!
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
--
Thomas Munro
https://enterprisedb.com
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:39 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Alex Aktsipetrov <alex.akts@gmail.com>
2019-07-08 23:49 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
@ 2019-07-09 01:13 ` Thomas Munro <thomas.munro@gmail.com>
2019-07-09 11:47 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Thomas Munro @ 2019-07-09 01:13 UTC (permalink / raw)
To: Alex Aktsipetrov <alex.akts@gmail.com>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Andres Freund <andres@anarazel.de>
On Tue, Jul 9, 2019 at 11:49 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Tue, Jul 9, 2019 at 11:39 AM Alex Aktsipetrov <alex.akts@gmail.com> wrote:
> > Attaching the patch that fixes the issue, although I am not familiar with the codebase to be sure that it is the right idea.
>
> Thanks for the report and the proposed fix!
The repro works for me, and I think the patch is correct. Here's a
version with that line moved to a more natural place IMHO.
> 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?
--
Thomas Munro
https://enterprisedb.com
Attachments:
[application/octet-stream] 0001-Pass-queryEnv-down-to-EvalPlanQual-s-EState.patch (1.2K, ../../CA+hUKG+XHZaCrX81CHwphG-dRTK_dmqWSmzW-vGYGEOGwZJjBw@mail.gmail.com/2-0001-Pass-queryEnv-down-to-EvalPlanQual-s-EState.patch)
download | inline diff:
From cec6ceb2f9c6d8db72a999cbad46457d4863ad9a Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Tue, 9 Jul 2019 12:53:35 +1200
Subject: [PATCH] Pass queryEnv down to EvalPlanQual's EState.
Otherwise the executor can't see trigger transition tables during
EPQ evaluation. Fixes bug #15900. Back-patch to 10, where trigger
transition tables landed.
Author: Alex Aktsipetrov
Discussion: https://postgr.es/m/15900-bc482754fe8d7415%40postgresql.org
---
src/backend/executor/execMain.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 27f03455152..29e2681484c 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -2793,6 +2793,7 @@ EvalPlanQualStart(EPQState *epqstate, EState *parentestate, Plan *planTree)
estate->es_range_table_array = parentestate->es_range_table_array;
estate->es_range_table_size = parentestate->es_range_table_size;
estate->es_relations = parentestate->es_relations;
+ estate->es_queryEnv = parentestate->es_queryEnv;
estate->es_rowmarks = parentestate->es_rowmarks;
estate->es_plannedstmt = parentestate->es_plannedstmt;
estate->es_junkFilter = parentestate->es_junkFilter;
--
2.21.0
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:39 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Alex Aktsipetrov <alex.akts@gmail.com>
2019-07-08 23:49 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 01:13 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
@ 2019-07-09 11:47 ` Thomas Munro <thomas.munro@gmail.com>
2019-07-09 15:38 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 9+ messages in thread
From: Thomas Munro @ 2019-07-09 11:47 UTC (permalink / raw)
To: Alex Aktsipetrov <alex.akts@gmail.com>; +Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Andres Freund <andres@anarazel.de>
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:39 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Alex Aktsipetrov <alex.akts@gmail.com>
2019-07-08 23:49 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 01:13 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 11:47 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
@ 2019-07-09 15:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-07-09 22:43 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-11 00:52 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Andres Freund <andres@anarazel.de>
0 siblings, 2 replies; 9+ messages in thread
From: Tom Lane @ 2019-07-09 15:38 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Alex Aktsipetrov <alex.akts@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Andres Freund <andres@anarazel.de>
Thomas Munro <thomas.munro@gmail.com> writes:
> On Tue, Jul 9, 2019 at 1:13 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> I think it's highly likely that bug #15720 was a case of this bug and
>> would be fixed by this patch.
Agreed. I think your version of the fix is good, and you should
mention #15720 too in the commit message.
>> 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 quite desperately unhappy about this observation, because
EvalPlanQualBegin is a *large* amount of overhead that is usually
unnecessary, and is now going to be paid for *every locked row*
whether there's any conflict on it or not. I do not find that
acceptable. Why is it necessary to do this before finding that
there's an update conflict?
regards, tom lane
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:39 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Alex Aktsipetrov <alex.akts@gmail.com>
2019-07-08 23:49 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 01:13 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 11:47 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 15:38 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Tom Lane <tgl@sss.pgh.pa.us>
@ 2019-07-09 22:43 ` Thomas Munro <thomas.munro@gmail.com>
1 sibling, 0 replies; 9+ messages in thread
From: Thomas Munro @ 2019-07-09 22:43 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alex Aktsipetrov <alex.akts@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>; Andres Freund <andres@anarazel.de>; Haribabu Kommi <kommi.haribabu@gmail.com>; Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
On Wed, Jul 10, 2019 at 3:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > On Tue, Jul 9, 2019 at 1:13 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> >> I think it's highly likely that bug #15720 was a case of this bug and
> >> would be fixed by this patch.
>
> Agreed. I think your version of the fix is good, and you should
> mention #15720 too in the commit message.
Thanks. Pushed.
> >> 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 quite desperately unhappy about this observation, because
> EvalPlanQualBegin is a *large* amount of overhead that is usually
> unnecessary, and is now going to be paid for *every locked row*
> whether there's any conflict on it or not. I do not find that
> acceptable. Why is it necessary to do this before finding that
> there's an update conflict?
I haven't seriously looked into it and haven't succeeded in finding
the discussion of why this is absolutely necessary in the commit's
thread, but you'd think it should be possible to defer slot creation a
bit, or if not, do something cheaper than EPQBegin() that just
initialises the slots. Andres, Haribabu, Ashutosh?
--
Thomas Munro
https://enterprisedb.com
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:39 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Alex Aktsipetrov <alex.akts@gmail.com>
2019-07-08 23:49 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 01:13 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 11:47 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Thomas Munro <thomas.munro@gmail.com>
2019-07-09 15:38 ` Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks Tom Lane <tgl@sss.pgh.pa.us>
@ 2019-07-11 00:52 ` Andres Freund <andres@anarazel.de>
1 sibling, 0 replies; 9+ messages in thread
From: Andres Freund @ 2019-07-11 00:52 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Alex Aktsipetrov <alex.akts@gmail.com>; PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Hi,
On 2019-07-09 11:38:13 -0400, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> >> 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 quite desperately unhappy about this observation, because
> EvalPlanQualBegin is a *large* amount of overhead that is usually
> unnecessary, and is now going to be paid for *every locked row*
> whether there's any conflict on it or not. I do not find that
> acceptable. Why is it necessary to do this before finding that
> there's an update conflict?
Two main reasons:
Previously we referenced tuples from LockRowsState->lr_curtuples, and
the management of that was pretty tightly interlinked with EPQ, and only
worked for heap tuples.Keeping that scheme would have been somewhat
complicated to continue to maintain.
Secondly, previously the tuple fetched by heap_lock_tuple() was just
stored in a local variable - but now that happens via a slot (as we
otherwise cannot reasonably handle things like heap wanting to return a
pinned buffer, and others not). As we potentially need to lock rows
from multiple tables, we'd need multiple slots suitable to lock/fetch those
rows.
EPQ already needed similar infrastructure internally - and those tuples
were fetched and retained for EPQ's benefit. So it seemed sensible to
just use the slots from EPQ. Note that we don't need
EvalPlanQualFetch() anymore, as it's work is done inside the AM -
obviously there's no AM independent way to perform correct ctid chasing.
Which large overhead you mean is going to be paid for "*every locked
row*"? EvalPlanQualBegin() ought to be fairly fast for repeated calls in
the same node - although I do admit that it'd be a lot nicer if the
ExecSetParamPlanMulti() work wouldn't need be redone.
I think it might be reasonable to split EvalPlanQualBegin() (and perhaps
EvalPlanQualStart()) into two pieces: One to just have a minimal
EPQState, with valid slots, and one to get ready to actually run EPQ?
Unfortunately I'm going to be unreachable pretty soon till Monday
(hiking without any network access), so I won't be immediately able to respond.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2019-07-11 00:52 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-07-08 22:22 BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks PG Bug reporting form <noreply@postgresql.org>
2019-07-08 23:32 ` Александр Акципетров <alex.akts@gmail.com>
2019-07-08 23:39 ` Alex Aktsipetrov <alex.akts@gmail.com>
2019-07-08 23:49 ` Thomas Munro <thomas.munro@gmail.com>
2019-07-09 01:13 ` Thomas Munro <thomas.munro@gmail.com>
2019-07-09 11:47 ` Thomas Munro <thomas.munro@gmail.com>
2019-07-09 15:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-07-09 22:43 ` Thomas Munro <thomas.munro@gmail.com>
2019-07-11 00:52 ` Andres Freund <andres@anarazel.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox