> Everything seems to work fine, except on the final call it has no more
> data to return so cleans up all it's internal data structures and
> returns with SRF_RETURN_DONE(funcctx).
If you are doing your development work on a Linux host, you may find it
useful to run the postmaster through valgrind
(http://en.wikipedia.org/wiki/Valgrind).
valgrind can spot many (but not all) memory-related problems and makes
it easier to track them to their source. Be aware that valgrind's
memory leak features may be pretty useless with PostgreSQL.
To run the server (and all backend processes) under valgrind:
$ valgrind --trace-children=yes --log-file=/tmp/pg.vg pg_ctl start
After that, you'll see one /tmp/pg.vg.<processID> file for each process
spawned by pg_ctl/postmaster. Use "SELECT * FROM pg_backend_pid()" to
find the processID of the backend where you are testing your extensions
and then look through the valgrind output file for that process.
-- Korry
--
Korry Douglas <korryd@enterprisedb.com> EnterpriseDB http://www.enterprisedb.com