Memory leak in FDW

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-04-26T18:06:51Z
Lists: pgsql-hackers

Attachments

Foreign data wrapper's IterateForeignScan() function is supposed to be 
called in a short-lived memory context, but the memory context is 
actually not reset during query execution. That's a pretty bad memory 
leak. I've been testing this with file_fdw and a large file, and "SELECT 
COUNT(*) FROM foreign_table"

Interestingly, if you add any WHERE clause to it, the memory context is 
reset in ExecScan and the leak goes away. This is only a problem with 
the fastpath in ExecScan for the case of no quals and no projections.

The trivial fix is to reset the per-tuple memory context between 
iterations. I tried to look around for other executor nodes that might 
have the same problem. I didn't see any obvious leaks, although index 
scan node seems to call AM's getnext without resetting the memory 
context in between. That's a pretty well-tested codepath, however, and 
there hasn't been any complains of leaks with index scans, so there must 
be something that mitigates it.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com