Re: autovacuum launcher process eating up 17G+ of ram? - Mailing list pgsql-admin

From Tom Lane
Subject Re: autovacuum launcher process eating up 17G+ of ram?
Date
Msg-id 4232.1288036630@sss.pgh.pa.us
Whole thread Raw
In response to Re: autovacuum launcher process eating up 17G+ of ram?  (Nick <t32@2thebatcave.com>)
Responses Re: autovacuum launcher process eating up 17G+ of ram?
List pgsql-admin
Nick <t32@2thebatcave.com> writes:
> It seems like the problem is a function of how many databases there are.

Yeah, I can reproduce this in HEAD.  Create a hundred or so databases,
and make sure there's a stats table entry for each, eg

create database d0;
\c d0
create table t1 as select generate_series(1,100000) x;
create database d1;
\c d1
create table t1 as select generate_series(1,100000) x;
create database d2;
\c d2
create table t1 as select generate_series(1,100000) x;
...

Set autovacuum_naptime to 1sec, and watch it bloat.  (It bloats faster
once it's run through the databases once and isn't mostly waiting for
children.)

It looks to me like the problem is that get_database_list()
intentionally pushes its result into a long-lived context, and then the
result is never cleaned up.  It doesn't help any that it does a lot of
leaky things like heap_beginscan with CurrentMemoryContext totally
unnecessarily pointing at the long-lived context.

I'm not sure what the intent was here, but it's pretty broken as-is.
Alvaro, what did you have in mind?  Should this be using a less
long-lived context, or do we need code to free an avw_dbase list?

            regards, tom lane

pgsql-admin by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: autovacuum launcher process eating up 17G+ of ram?
Next
From: "Gnanakumar"
Date:
Subject: Re: pg_ctl: server does not shut down