Re: troubleshooting pointers - Mailing list pgsql-hackers

From Joe Conway
Subject Re: troubleshooting pointers
Date
Msg-id 3CDB096C.40005@joeconway.com
Whole thread Raw
In response to troubleshooting pointers  (Joe Conway <mail@joeconway.com>)
Responses Re: troubleshooting pointers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> 
>>With the current SRF patch, in certain circumstances selecting from a 
>>VIEW produces "Buffer Leak" warnings, while selecting from the function 
>>itself does not. Also the VIEW returns only one of the two expected 
>>rows.
> 
> The buffer leak suggests failure to shut down a plan tree (ie, no
> ExecutorEnd call).  Probably related to not running the VIEW to
> completion, but it's hard to guess at the underlying cause.
> 
> Do the plan trees (EXPLAIN display) look the same in both cases?

Yes, but it suffers from the issue you brought up yesterday -- i.e. 
EXPLAIN doesn't run from within the function, and EXPLAIN outside the 
function (or VIEW which calls it) doesn't show very much:

test=# EXPLAIN SELECT * FROM vw_getfoo;                        QUERY PLAN
----------------------------------------------------------- Function Scan on getfoo  (cost=0.00..0.00 rows=0 width=0)
(1 row)

test=# EXPLAIN SELECT * FROM getfoo(1);                        QUERY PLAN
----------------------------------------------------------- Function Scan on getfoo  (cost=0.00..0.00 rows=0 width=0)
(1 row)

I found an explaination you gave a while back which sounds like it 
explains the problem:
http://archives.postgresql.org/pgsql-bugs/2001-06/msg00051.php

I also confirmed that postquel_end(), which calls ExecutorEnd(), never 
gets called for the VIEW case (or the LIMIT case that was pointed out on 
an earlier post).

Just now I was looking for a way to propagate the necessary information 
to call ExecutorEnd() from ExecEndFunctionScan() in the case that fmgr 
doesn't. It looks like I might be able to add a member to the 
ExprContext struct for this purpose. Does this sound like the correct 
(or at least a reasonable) approach?

Thanks,

Joe




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: troubleshooting pointers
Next
From: Tom Lane
Date:
Subject: Re: www.pgaccess.org - the official story (the way I saw