Re: Oversight in reparameterize_path_by_child leading to executor crash

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Oversight in reparameterize_path_by_child leading to executor crash
Date: 2023-08-02 11:02:38
Message-ID: CAMbWs4_vPd1yvxhiwD67o5cBsmgWc-py+B8gFFDDTrTQY5EXeg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> Richard Guo <guofenglinux(at)gmail(dot)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

Attachment Content-Type Size
v2-0001-Postpone-reparameterization-of-paths-until-when-creating-plans.patch application/octet-stream 14.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2023-08-02 11:44:42 Re: Potential memory leak in contrib/intarray's g_intbig_compress
Previous Message Melih Mutlu 2023-08-02 10:39:07 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication