From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
Date: Thu, 15 Apr 2010 18:48:17 -0400
Message-ID: <26178.1271371697@sss.pgh.pa.us> (raw)
In-Reply-To: <4BC79072.10901@agliodbs.com>
References: <4BC76C9F.1020200@agliodbs.com>
<20100415200056.GJ7259@alvh.no-ip.org>
<16088.1271362441@sss.pgh.pa.us>
<20100415202405.GL7259@alvh.no-ip.org>
<4BC79072.10901@agliodbs.com>
Josh Berkus <josh@agliodbs.com> writes:
>> But it shouldn't
>> be sleeping after each page with normal cost_delay parameters, should it?
> Right, that's why I find this puzzling. If the problem was easier to
> reproduce it would be easier to analyze.
The behavior would be explained if VacuumCostLimit were getting set to
zero (or some unreasonably small value) in the autovac worker process.
I looked at the autovac code that manages that, and it seems complicated
enough that a bug wouldn't surprise me in the least.
I especially note that wi_cost_limit is explicitly initialized to zero,
rather than something sane; and that table_recheck_autovac falls back to
setting vac_cost_limit from the previous value of VacuumCostLimit
... which is NOT constant but in general is left over from the
previously processed table. One should also keep in mind that SIGHUP
processing might reload VacuumCostLimit from GUC values. So I think
that area needs a closer look.
Josh, are you sure that both servers are identical in terms of both
GUC-related and per-table autovacuum settings?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, josh@agliodbs.com, alvherre@commandprompt.com
Subject: Re: Autovaccum with cost_delay does not complete on one solaris 5.10 machine
In-Reply-To: <26178.1271371697@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox