Profiling vs autovacuum (was Re: building 8.3beta2 w/ 'make check' consumes A LOT of disk space)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Profiling vs autovacuum (was Re: building 8.3beta2 w/ 'make check' consumes A LOT of disk space)
Date: 2007-11-04 03:06:21
Message-ID: 4285.1194145581@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> However, accumulation of zillions of gmon.out files is definitely a
> downside of the approach; one that I've noticed myself. I've also
> noticed that it takes a heck of a long time to rm -rf $PGDATA once
> you've built up a few tens of thousands of gprof subdirectories. What's
> worse, this accumulation will occur pretty quick even if you're not
> doing anything with the DB, because of autovacuum process launches.

> I wonder if we need to rein in gmon.out accumulation somehow, and if
> so how? This isn't an issue for ordinary users but I can see it
> becoming a PITA for developers.

On reflection, it seems like the worst part of this is the steady
accumulation of gprof files from autovacuum workers, which are unlikely
to be of interest at all (if you want to profile vacuuming, you'd
probably issue manual vacuum commands anyway). So I propose something
like the attached, untested patch to force all AV workers to dump to the
same gmon.out file. Comments?

regards, tom lane

Attachment Content-Type Size
unknown_filename text/plain 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-11-04 07:36:40 Re: Profiling vs autovacuum
Previous Message Neil Conway 2007-11-04 02:35:20 "bad key in cancel request"