Richard Guo writes:
> I see. I didn't notice any real issues with that; I was just flagged
> by the XXX comment there, which raises the question of whether it's
> worth working harder to determine the inputOps.
I was intending to add some code to my nodeSetop patch to see if
both input plan node
On Thu, Dec 19, 2024 at 8:10 AM Tom Lane wrote:
> David Rowley writes:
> > I propose to quickly do a master-only follow-up commit to use the
> > inputOps instead of NULL in BuildTupleHashTableExt (Basically Tom's
> > patch from [1])
>
> LGTM.
+1.
Thanks
Richard
On Wed, Dec 18, 2024 at 7:45 PM David Rowley wrote:
> On Wed, 18 Dec 2024 at 22:29, Richard Guo wrote:
> > Should we be concerned about passing a NULL TupleTableSlotOps in
> > nodeRecursiveUnion.c?
>
> I made it pass NULL on purpose because the slot type on the recursive
> union can be different
David Rowley writes:
> On Wed, 18 Dec 2024 at 23:45, David Rowley wrote:
>> Maybe we need to backpatch passing NULL instead of &TTSOpsMinimalTuple
>> to ExecBuildGroupingEqual() in BuildTupleHashTableExt(). Something
>> like the attached patch.
> I've attached a more formal patch for this and I'
On Wed, 18 Dec 2024 at 23:45, David Rowley wrote:
> Maybe we need to backpatch passing NULL instead of &TTSOpsMinimalTuple
> to ExecBuildGroupingEqual() in BuildTupleHashTableExt(). Something
> like the attached patch.
I've attached a more formal patch for this and I've also now done a
bit more r
On Wed, 18 Dec 2024 at 22:29, Richard Guo wrote:
> Should we be concerned about passing a NULL TupleTableSlotOps in
> nodeRecursiveUnion.c?
I made it pass NULL on purpose because the slot type on the recursive
union can be different on the inner and outer sides. Do you see issues
with that?
> Th
On Wed, Dec 18, 2024 at 7:05 AM Tom Lane wrote:
> David Rowley writes:
> > The slightly annoying thing here is that the attached patch passes the
> > TupleTableSlotOps as NULL in nodeSetOp.c. Per nodeAppend.c line 186,
> > Append does not go to much effort to setting a fixed
> > TupleTableSlotOps
David Rowley writes:
> On Wed, 18 Dec 2024 at 14:02, Tom Lane wrote:
>> it appears your patch did not fully adjust BuildTupleHashTableExt
>> for variable input-slot type. You need the attached as well.
> Do you have a test case in master that triggers a problem here?
No, that's what I didn't w
On Wed, 18 Dec 2024 at 14:02, Tom Lane wrote:
> So I tried adapting my patch to not make a copy of the input slot,
> and it didn't work: I was still getting assertion failures about
> the slot not being a MinimalTupleSlot as expected. On investigation
> it appears your patch did not fully adjust
David Rowley writes:
> I've pushed the patch now.
So I tried adapting my patch to not make a copy of the input slot,
and it didn't work: I was still getting assertion failures about
the slot not being a MinimalTupleSlot as expected. On investigation
it appears your patch did not fully adjust Bui
On Wed, 18 Dec 2024 at 11:04, Tom Lane wrote:
>
> David Rowley writes:
> > project and use a virtual slot type. It's maybe worth coming back and
> > adjusting nodeAppend.c so it works a bit harder to fix its slot type.
> > I think that's likely for another patch, however. Tom is also
> > curren
David Rowley writes:
> The slightly annoying thing here is that the attached patch passes the
> TupleTableSlotOps as NULL in nodeSetOp.c. Per nodeAppend.c line 186,
> Append does not go to much effort to setting a fixed
> TupleTableSlotOps. Really it could loop over all the child plans and
> check
On Tue, 17 Dec 2024 at 07:10, Nathan Bossart wrote:
> git-bisect is pointing me to https://postgr.es/c/0f57382. Here is the
> trace I'm seeing:
>
> TRAP: failed Assert("op->d.fetch.kind == slot->tts_ops"), File:
> "../postgresql/src/backend/executor/execExprInterp.c", Line: 2244, PID: 50
On Tue, 17 Dec 2024 at 07:10, Nathan Bossart wrote:
> On Mon, Dec 16, 2024 at 09:50:39AM -0800, Paul Ramsey wrote:
> > CREATE TABLE foo (id integer, x integer, y integer);
> > INSERT INTO foo VALUES (1, 0, 1);
> > INSERT INTO foo VALUES (2, 1, 2);
> > INSERT INTO foo VALUES (3, 2, 3);
> >
> > WITH
Thanks for the report!
On Mon, Dec 16, 2024 at 09:50:39AM -0800, Paul Ramsey wrote:
> Apologies if this is already reported, but there´s a crasher in recursive
> queries at the head of the current development that happened to be
> exercised by our regression suite. Here is a core-only reproduction
15 matches
Mail list logo
