Re: Pg18 Recursive Crash - Mailing list pgsql-hackers

From David Rowley
Subject Re: Pg18 Recursive Crash
Date
Msg-id CAApHDvqOHJ1gWjbw8wZ4U1G1RQefEj_CnJB4Rmw=PFru8jbRog@mail.gmail.com
Whole thread Raw
In response to Re: Pg18 Recursive Crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Pg18 Recursive Crash
List pgsql-hackers
On Wed, 18 Dec 2024 at 11:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> 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
> > currently working on nodeSetOps.c to change how all this works so it
> > no longer uses the flags method to determine the outer and inner
> > sides.
>
> Yeah, I see no point in putting effort into improving the current
> nodeSetOp implementation.  There might be a reason to change
> nodeAppend as you suggest for other use-cases though.

I'll have a look to see what's possible here. Maybe locally adding
some telemetry output to the regression tests to log when an ExprState
performs a deform operation would be good to test with and without the
said patch to see how widespread an improvement the patch would result
in. I expect it might be most useful for partition-wise joins, but
that'll much depend on what operations occur above the Append.

> > I plan to push the attached patch soon.
>
> I'll presumably need to rebase my nodeSetOp patch when this goes
> in.  I'll take a look then at whether the new code can be improved
> with this additional feature.

I've pushed the patch now.

David



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Eagerly scan all-visible pages to amortize aggressive vacuum
Next
From: Heikki Linnakangas
Date:
Subject: Re: Exceptional md.c paths for recovery and zero_damaged_pages