Hi,
we got a report of (probably) the same issue on a local mailing list.
Maybe it'll help in finding the root cause, so I'm resending the info
here too.
On 21.4.2013 01:19, Adrian Klaver wrote:
> On 04/20/2013 04:08 PM, Daniel Cristian Cruz wrote:
>> I think I didn't make it clear: the session memory usage is growing up
>> too fast, until all server memory got used and swap occurs.
>>
>> Never saw something like that. The version is under a test enviroment
>> for a long time...
>>
>> Thanks if someone could help me.
>
> Before any one can help I would think more information is needed;
>
> 1) Is it on the same machine/OS as the old version?
Yes. This was an upgrade from 9.2.3 to 9.2.4, so this was the usual
minor upgrade procedure - stop, install 9.2.4 package, start.
AFAIK there was no other change (e.g. update of kernel).
> 2) What are the hardware specs for the machine?
32GB of RAM, 6 cores. I don't know which linux distribution they run.
The interesting part is they have a lot of tables due to a partitioned
schema. In total there's ~9500 tables.
> 3) Is it still in test mode or in production?
It's in production for a long time and so far it was running fine, until
the upgrade to 9.2.4.
> 4) You seem to imply that in test mode everything worked alright, is
> that the case?
It was working fine in the production (exactly the same workload) for a
long time (few months at least).
> 5) In either case, test/production, what is being done in the session(s)?
Simple selects, mostly index scans, nothing complex or time consuming.
There's not a particular query that crashes, it's rather about a
combination of queries.
> 6) Is there anything in the Postgres logs that might shed light?
I do have a log with the memory context info printed after the OOM
killed the session - see it attached.
Tomas
