On 4/12/2013 1:57 PM, Tom Lane wrote:
Kevin Grittner <kgri...@ymail.com> writes:
Tom Lane <t...@sss.pgh.pa.us> wrote:
I think that the minimum appropriate fix here is to revert the hunk
I quoted, ie take out the suppression of stats reporting and analysis.
I'm not sure I understand -- are you proposing that is all we do
for both the VACUUM command and autovacuum?
No, I said that was the minimum fix.
Looking again at the patch, I note this comment:
/*
+ * We failed to establish the lock in the specified number of
+ * retries. This means we give up truncating. Suppress the
+ * ANALYZE step. Doing an ANALYZE at this point will reset the
+ * dead_tuple_count in the stats collector, so we will not get
+ * called by the autovacuum launcher again to do the truncate.
+ */
and I suppose the rationale for suppressing the stats report was this
same idea of lying to the stats collector in order to encourage a new
vacuum attempt to happen right away. Now I'm not sure that that's a
good idea at all --- what's the reasoning for thinking the table will be
any less hot in thirty seconds? But if it is reasonable, we need a
redesign of the reporting messages, not just a hack to not tell the
stats collector what we did.
Yes, that was the rationale behind it combined with "don't change
function call sequences and more" all over the place.
The proper solution would eventually be to add a block number to the
stats held by the stats collector, which preserves the information about
the last filled block of the table. The decouple the truncate from
vacuum/autovacuum. vacuum/autovacuum will set that block number when
they detect the trailing free space. The analyze step can happen just as
usual and reset stats, which doesn't reset that block number. The
autovacuum launcher goes through its normal logic for launching autovac
or autoanalyze. If it doesn't find any of those to do but the
last-used-block is set, it launches the separate lazy truncate step.
This explicitly moves the truncate, which inherently requires the
exclusive lock and therefore is undesirable even in a manual vacuum,
into the background.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
