Re: (auto)vacuum truncate exclusive lock - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: (auto)vacuum truncate exclusive lock
Date
Msg-id 517014C2.80004@Yahoo.com
Whole thread Raw
In response to Re: (auto)vacuum truncate exclusive lock  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: (auto)vacuum truncate exclusive lock
List pgsql-hackers
On 4/12/2013 1:57 PM, Tom Lane wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> Tom Lane <tgl@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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: event trigger API documentation?
Next
From: Jan Wieck
Date:
Subject: Re: (auto)vacuum truncate exclusive lock