From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeremy Palmer <JPalmer(at)linz(dot)govt(dot)nz> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 9.0 Out of memory |
Date: | 2011-04-13 18:15:30 |
Message-ID: | 9471.1302718530@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jeremy Palmer <JPalmer(at)linz(dot)govt(dot)nz> writes:
> The plpgsql code that is could be to blame is in the below snippet. I had a look and I'm not sure why it might be leaking. Is it because I assign the v_id1 and v_id2 to the return table 'id' record, return it and then assign to v_id1 or v_id2 again from the cursor?
No, given the info from the memory map I'd have to say that the leakage
is in the cursor not in what you do in the plpgsql function. The cursor
query looks fairly unexciting except for the cast from geometry to text.
I don't have PostGIS installed here so I can't do any testing, but I
wonder whether the leak goes away if you remove that part of the query
(ie, leave the shape out of the "checksum" for testing purposes).
If so, you probably ought to file the issue as a PostGIS bug.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Henry C. | 2011-04-13 18:15:54 | Replication: slave is in permanent startup 'recovery' |
Previous Message | Tom Lane | 2011-04-13 18:06:57 | Re: Streaming Replication limitations |