> Yeah, I remember we found a few xml-related leaks based on your reports. > However, there's not anything here to suggest that this query is > straining the capabilities of a 64-bit system with lots o RAM. It seems > certain you're hitting some artificial process-size limit, and the only > one I know about is ulimit. > > I wasn't aware of /proc/<pid>/limits before, but now that I've heard > of it, checking that for the postmaster and/or a backend seems like > a great idea.
This doesn't seem to exist for any process on this box: [r...@170226-db7 ~]# ls /proc/*/limit* ls: /proc/*/limit*: No such file or directory If this were a system-defined process-size limit, then should the query still run out of memory after restarting Postgres? Most likely we'll have to restart Postgres soon, and I'll retry this query after doing so. Based on past experience, I'd expect the query to complete at that time. >From what we experience, Postgres seems to be slowly accumulating memory in the fashion of a small memory leak and things start to fail with out-of-memory errors after the server has been running for some time (e.g. roughly 4-6 weeks). Restarting Postgres clears out the problems (after a restart we can immediately run queries that were failing before the restart)... but then the cycle starts again. I just bring this up wondering if there is something possibly accumulating within Postgres that isn't getting freed and might cause an out-of-memory error like this in some way. Regards, Matt -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
