Re: Oversight in reparameterize_path_by_child leading to executor crash

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2023-08-02T11:02:38Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Postpone reparameterization of paths until create_plan().
- b7e2121ab7d6 17.0 landed
Apply band-aid fix for an oversight in reparameterize_path_by_child.
- e031995d5c26 14.11 landed
- 7af96a66f43c 13.14 landed
- 62f120203147 16.2 landed
- 2e822a1d62d0 12.18 landed
- 12ec16d11c8b 15.6 landed

Attachments

v2-0001-Postpone-reparameterization-of-paths-until-when-creating-plans.patch (application/octet-stream) patch v2-0001

On Tue, Aug 1, 2023 at 9:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Richard Guo <guofenglinux@gmail.com> writes:
> > So what I'm thinking is that maybe we can add a new type of path, named
> > SampleScanPath, to have the TableSampleClause per path.  Then we can
> > safely reparameterize the TableSampleClause as needed for each
> > SampleScanPath.  That's what the attached patch does.
>
> Alternatively, could we postpone the reparameterization until
> createplan.c?  Having to build reparameterized expressions we might
> not use seems expensive, and it would also contribute to the memory
> bloat being complained of in nearby threads.

I did think about this option but figured out that it seems beyond the
scope of just fixing SampleScan.  But if we want to optimize the
reparameterization mechanism besides fixing this crash, I think this
option is much better.  I drafted a patch as attached.

Thanks
Richard