<mailto:tv@fuzzy.cz <mailto:tv@fuzzy.cz>>> writes: > I do have a log with the memory context info printed after the OOM > killed the session - see it attached.
The only thing that seems rather bloated is the CacheMemoryContext, which seems to be because the backend has cached info about several thousand tables and indexes. Given that you say there's 9500 relations in their schema, it's hard to believe that 9.2.4 is suddenly doing that where 9.2.3 didn't. I'm wondering if they've done something else that restricted the amount of memory available to a backend.
Maybe, since I'm running the same server and top shows a RES size a bit large for idle sessions. Not so large than 9.2. Bellow is the actual server top.
Just to be clear the below is for the 9.1.4 server you rolled backed to?
Yes.
To recap for those following along, there are two different cases in play here.
1) Major upgrade from 9.1.4 to 9.2.4. Used pg_upgrade Tested on VM with 9.2.4 and no problems. Same machine used for production server 9.1.4 and 9.2.4 When complex queries where run on production server under 9.2.4 memory usage climbed out of control.
Unanswered questions:
a) Data set sizes between test and production machines, how do they differ?
It's the same on both; we do a dump/restore every day to the development / issue team work.
b) What are the EXPLAIN/ANALYZE results for a query on 9.1.4, 9.2.4 test and 9.2.4 production?
Since there is no single query causing the problem, I don't know if it could help.
One thing I didn't mention: I build a record table used to track every transaction on database, and all tables are inherited from it. This way I easily found the records to transfer from 9.2.4 to 9.1.x.
But it's something similar with the other case, where they are using for partitioning purposes, and I'm using to simplify the model (the inherited table is hidden in the model).