From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16801: Invalid memory access on WITH RECURSIVE with nested WITHs |
Date: | 2021-02-25 02:13:46 |
Message-ID: | 51877.1614219226@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> Yes, thanks. While looking at that this morning, I have been able to
> get a crash with my previous patch once I used more nesting in those
> CTEs and your test is much simpler. I also got a test case able to
> break things the same way in checkWellFormedRecursionWalker():
> WITH RECURSIVE outermost(x) AS (
> SELECT 1
> UNION (WITH innermost as (WITH innermost2 AS (SELECT 2) SELECT * FROM innermost2)
> SELECT * FROM outermost
> UNION SELECT * FROM innermost)
> )
> SELECT * FROM outermost ORDER BY 1;
Hmm, I don't see any failure from that...
In my understanding of the bug, you need at least half a dozen levels of
WITH nesting to provoke a problem, because nothing will go wrong until the
innerwiths list gets to be six entries long, causing list.c to move its
elements array to somewhere else. If it is possible to fail without that
then there's still something here that I don't get.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-02-25 02:17:09 | Re: BUG #16801: Invalid memory access on WITH RECURSIVE with nested WITHs |
Previous Message | Michael Paquier | 2021-02-25 01:30:41 | Re: BUG #16801: Invalid memory access on WITH RECURSIVE with nested WITHs |