Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id A438565005C;
	Wed, 23 Jul 2008 22:06:14 -0300 (ADT)
Received: from postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 90088-03; Wed, 23 Jul 2008 22:05:49 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from fetter.org (start.fetter.org [66.92.188.65])
	by postgresql.org (Postfix) with ESMTP id ECF2064FD1A;
	Wed, 23 Jul 2008 22:05:52 -0300 (ADT)
Received: by fetter.org (Postfix, from userid 500)
	id D6297FBC62D; Wed, 23 Jul 2008 18:05:50 -0700 (PDT)
Date: Wed, 23 Jul 2008 18:05:50 -0700
From: David Fetter <david@fetter.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tatsuo Ishii <ishii@postgresql.org>, pgsql-patches@postgresql.org,
	pgsql-hackers@postgresql.org, y-asaba@sraoss.co.jp
Subject: Re: [PATCHES] WITH RECUSIVE patches 0723
Message-ID: <20080724010550.GA1938@fetter.org>
References: <20080723.225435.55841946.t-ishii@sraoss.co.jp>
	<15216.1216825160@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15216.1216825160@sss.pgh.pa.us>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200807/1105
X-Sequence-Number: 121365

On Wed, Jul 23, 2008 at 10:59:20AM -0400, Tom Lane wrote:
> Tatsuo Ishii <ishii@postgresql.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.
0x08192dcd in ExecQual (qual=0xa183824, econtext=0xa183230, resultForNull=0 '\0') at execQual.c:4513
4513            expr_value = ExecEvalExpr(clause, econtext, &isNull, NULL);
(gdb) i s
#0  0x08192dcd in ExecQual (qual=0xa183824, econtext=0xa183230, resultForNull=0 '\0') at execQual.c:4513
#1  0x08199b23 in ExecScan (node=0xa1831a4, accessMtd=0x81a6bb0 <RecursivescanNext>) at execScan.c:131
#2  0x081a6ba9 in ExecRecursiveScan (node=0xa1831a4) at nodeRecursivescan.c:48
#3  0x08192320 in ExecProcNode (node=0xa1831a4) at execProcnode.c:380
#4  0x081a6923 in RecursionNext (node=0xa17fe18) at nodeRecursion.c:68
#5  0x08199a83 in ExecScan (node=0xa17fe18, accessMtd=0x81a6840 <RecursionNext>) at execScan.c:68
#6  0x081a6839 in ExecRecursion (node=0xa17fe18) at nodeRecursion.c:116
#7  0x081923e0 in ExecProcNode (node=0xa17fe18) at execProcnode.c:339
#8  0x081a1c13 in MultiExecHash (node=0xa17fcc4) at nodeHash.c:94
#9  0x081a28b9 in ExecHashJoin (node=0xa17b654) at nodeHashjoin.c:159
#10 0x081922d8 in ExecProcNode (node=0xa17b654) at execProcnode.c:395
#11 0x081901db in standard_ExecutorRun (queryDesc=0xa15c334, direction=ForwardScanDirection, count=0) at execMain.c:1271
#12 0x08240dc4 in PortalRunSelect (portal=0xa15631c, forward=1 '\001', count=0, dest=0xa1733d8) at pquery.c:937
#13 0x082420e6 in PortalRun (portal=0xa15631c, count=2147483647, isTopLevel=1 '\001', dest=0xa1733d8, altdest=0xa1733d8, 
    completionTag=0xbfcacaea "") at pquery.c:793
#14 0x0823d0a7 in exec_simple_query (
    query_string=0xa12fc9c "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);") at postgres.c:977
#15 0x0823e84c in PostgresMain (argc=4, argv=0xa0d0dac, username=0xa0d0d7c "shackle") at postgres.c:3559
#16 0x0820957f in ServerLoop () at postmaster.c:3238
#17 0x0820a4e0 in PostmasterMain (argc=3, argv=0xa0ced50) at postmaster.c:1023
#18 0x081b69d6 in main (argc=3, argv=0xa0ced50) at main.c:188

What other information could help track down this problem?

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate