> 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:
[root@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