>> Ok I removed the geometry column from the cursor query within the function and the session still runs out of memory. I'm still seeing the same error message as well: >> PortalHeapMemory: 16384 total in 4 blocks; 5944 free (0 chunks); 10440 used >> ExecutorState: 122880 total in 4 blocks; 63984 free (8 chunks); 58896 used >> ExprContext: 2496819768 total in 9 blocks; 21080 free (15 >> chunks); 2496798688 used >> So I guess it's not likely to be the PostGIS geometry to text cast that is leaking the memory. >OK, so that was a wrong guess. Hi Tom, I finally tracked down the issue! The query that was generating the temp table which was used as input into the 2 cursor queries was generating an invalid, very large geometry (like 200mb). It turned out I had a bug in the previous testing I was doing, and I didn't actually remove the geometry column from the second cursor. So I guess a 200mb geometry being cast to text used too much memory. Not sure if there is still a leak... But I guess that depends on weather the geometry expands to over 1 GB when converted to text. Anyway I would like to personally thank you for you time in helping me with this issue. Regards, Jeremy ______________________________________________________________________________________________________ This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@xxxxxxxxxxxx) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank you. ______________________________________________________________________________________________________ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
