Re: 9.0 Out of memory

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

In response to

Responses

Browse pgsql-general by date

  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