Re: [PATCHES] WITH RECUSIVE patches 0723

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: david(at)fetter(dot)org
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, ishii(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, y-asaba(at)sraoss(dot)co(dot)jp
Subject: Re: [PATCHES] WITH RECUSIVE patches 0723
Date: 2008-07-24 04:55:37
Message-ID: 20080724.135537.44977938.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> On Wed, Jul 23, 2008 at 10:59:20AM -0400, Tom Lane wrote:
> > Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> > > Reviewers, please let me know if you find problems with the
> > > patches. If none, I would like to commit this weekend.
> >
> > Has this patch actually been reviewed yet? The only reports I've
> > seen are from testing; nothing from anyone actually reading the
> > code. I know I've not looked at it yet.
>
> I've read the code, for what that's worth, which isn't much. I just
> tried out this patch on a fresh checkout of CVS TIP and found:
>
> EXPLAIN WITH RECURSIVE t(i) AS (VALUES(1::int) UNION ALL SELECT i+1 FROM t WHERE i < 5) SELECT * FROM t AS t1 JOIN t AS t2 USING(i);
> QUERY PLAN
> -------------------------------------------------------------------------------------
> Hash Join (cost=0.08..0.16 rows=2 width=4)
> Hash Cond: (t1.i = t2.i)
> -> Recursion on t1 (cost=0.00..0.06 rows=2 width=4)
> -> Append (cost=0.00..0.04 rows=2 width=4)
> -> Values Scan on "*VALUES*" (cost=0.00..0.01 rows=1 width=4)
> -> Recursive Scan on t (cost=0.00..0.00 rows=1 width=4)
> Filter: (i < 5)
> -> Hash (cost=0.06..0.06 rows=2 width=4)
> -> Recursion on t2 (cost=0.00..0.06 rows=2 width=4)
> -> Append (cost=0.00..0.04 rows=2 width=4)
> -> Values Scan on "*VALUES*" (cost=0.00..0.01 rows=1 width=4)
> -> Recursive Scan on t (cost=0.00..0.00 rows=1 width=4)
> Filter: (i < 5)
> (13 rows)
>
> When I try to execute the query without the EXPLAIN, having attached a debugger
> to the back-end, I get.
>
> (gdb) continue
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.

Thanks for the report. Here is the new patches from Yoshiyuki. It
appeared that addRangeTableEntryForRecursive() needs to do deep copy
for the subquery and ref in the RangeTblEntry to avoid double free
bug (remember that your example is a self join case).

Also I added your query to the regression test case with minor
modifications.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Attachment Content-Type Size
recursive_query.patch.gz application/octet-stream 27.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-07-24 05:49:15 Re: Research/Implementation of Nested Loop Join optimization
Previous Message Stephen Frost 2008-07-24 03:20:47 Re: pg_dump additional options for performance

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2008-07-24 07:37:11 Re: pg_dump additional options for performance
Previous Message Stephen Frost 2008-07-24 03:20:47 Re: pg_dump additional options for performance