Occams razor says it's PostGIS. However, I'm concerned about how old the code being run is. In particular, the library underneath PostGIS, GEOS, had a *lot* of memory work done on it over the last year. I'd like to see if things improve if you upgrade to GEOS 3.2. On Fri, Mar 26, 2010 at 9:04 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Frans Hals <fhals7@xxxxxxxxxxxxxx> writes: >> Operation is now running for around 13 hrs. >> Two postmaster processes above 1% memory usage are running. > >> One of them uses constantly 26.5% of memory. >> The other one is growing: >> After 1 hr 25% >> After 9 hrs 59% >> After 13 hrs 64% > > Well, it's pretty clear that you've found a memory leak, but that was > what we thought before; this data doesn't move us any closer to a fix. > In particular it's not possible to guess whether the leak should be > blamed on Postgres or Postgis code. Even if we knew that, I'm not > sure we could fix the leak without tracing through actual execution. > > Can you generate a self-contained test case that exhibits similar bloat? > I would think it's probably not very dependent on the specific data in > the column, so a simple script that constructs a lot of random data > similar to yours might be enough, if you would rather not show us your > real data. > > regards, tom lane > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
