Horton

Re: BUG #18077: PostgreSQL server subprocess crashed by a SELECT statement with WITH clause

Andrei Lepikhov <a.lepikhov@postgrespro.ru>

View thread View on postgr.es
From: "Lepikhov Andrei" <a.lepikhov@postgrespro.ru>
To: "Michael Paquier" <michael@paquier.xyz>
Cc: "Richard Guo" <guofenglinux@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>, fuboat@outlook.com, pgsql-bugs@lists.postgresql.org
Date: 2023-09-11T03:15:02Z
Lists: pgsql-bugs

Attachments


On Thu, Sep 7, 2023, at 4:46 PM, Michael Paquier wrote:
> On Thu, Sep 07, 2023 at 03:25:36PM +0700, Lepikhov Andrei wrote:
>> I invented a dummy extension "pg_extension" [1], commit 4199a0c,
>> which adds  CustomScan over the first non-parameterized HashJoin at
>> the pathlist. 
>> The example presented in my letter earlier causes the ERROR on
>> CTE. Moreover, if you remove the word 'materialized', you will find
>> the same error on Subquery.
>> 
>> [1] https://github.com/danolivo/pg_extension/tree/main
>
> Digressing a bit here about this point..  In the long-term I think
> that it would be a good idea to have a template module in
> src/test/modules/ that shows how to use a CustomScan so as it is able
> to demonstrate how this stuff works, and to check if it is works as
> intended.  With regression tests, of course.

I agree. I often use it in different situations: for scan, join purposes, as a stat gathering tool and others. Having some templates in the code base would be comfortable. Also, We should remember to add some examples of extensible node usage ...
In the attachment - rewritten code of the CustomScan node, as mentioned earlier, as a test module with one regression test. It shows both CTE and Subquery problems (they have different sources of error). Also, I have attached a patch that fixes the problem's symptoms - not the origins of the problem, just for demonstration.

-- 
Regards,
Andrei Lepikhov

Commits

  1. Track nesting depth correctly when drilling down into RECORD Vars.

  2. Fix get_expr_result_type() to find field names for RECORD Consts.

  3. Allow extracting fields from a ROW() expression in more cases.