Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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: recursive_query.patch.gz
Description: application/octet-stream (27.1 KB)

In response to

Responses

pgsql-hackers by date

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

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-07-24 07:37:11
Subject: Re: pg_dump additional options for performance
Previous:From: Stephen FrostDate: 2008-07-24 03:20:47
Subject: Re: pg_dump additional options for performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group