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  <[EMAIL PROTECTED]>
 EnterpriseDB    http://www.enterprisedb.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to