(auto)vacuum truncate exclusive lock

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: (auto)vacuum truncate exclusive lock
Date: 2013-04-12 04:02:49
Message-ID: CAMkU=1xsLwgLXMKABD5cRhxXh=C9gui99nZzcc09-OHmLv8cdw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, April 11, 2013, Tom Lane wrote:

> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> > I guess I'm a couple releases late to review the "autovacuum truncate
> > exclusive lock" patch (a79ae0bc0d454b9f2c95a), but this patch did not
> only
> > affect autovac, it affects manual vacuum as well (as did the original
> > behavior it is a modification of). So the compiler constants are
> misnamed,
> > and the elog message when it triggers is misleading. (Is it also
> > misleading to just say "vacuum"? Does it need to say "(auto)vacuum"?)
>
> I just came to look at this via a complaint in pgsql-admin. I'm not
> convinced that we should consider the new behavior to be sane.
> Automatic exclusive-lock abandonment makes sense for autovacuum, but
> when the user has told us to vacuum, ISTM we should do it. I can see
> there might be differing opinions on that though.
>

It does do the vacuum (so that internal space can be re-used, etc.), it is
the truncation of > 8MB of terminal free space that it may or may not do.

In this regard, the old behavior of manual vacuum was not all that
consistent, either. If it could not get the lock immediately, it would
abandon the attempt to truncation (but still do the analyze, unlike now).
But if the lock was immediately available, it would take it and hold it
for as long as it took. It is an odd mixture of courtesy and
aggressiveness to not wait for a lock if unavailable, but if obtained to
cling to it (justified by the ease of implementation, I guess).

I think the manual vacuum should try to obtain the lock for 5 seconds, as
in the current behavior. Whether once obtained it should cling to it, or
surrender it, I don't really know.

>
> > Also, I think that permanently boycotting doing autoanalyze because
> someone
> > is camping out on an access share lock (or because there are a
> never-ending
> > stream of overlapping locks) and so the truncation cannot be done is a
> bit
> > drastic, especially for inclusion in a point release.
>
> It's worse than that, it breaks manual VACUUM ANALYZE too (as per -admin
> complaint). I think this aspect is completely wrong, whether or not
> you consider that dropping the exclusive lock early is sane for manual
> vacuum. If we were told to do an analyze, we should press on and do it.
>
> Thoughts?
>

I don't think auto-analyze should get cancelled either.

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2013-04-12 05:48:01 Re: Inconsistent DB data in Streaming Replication
Previous Message Michael Paquier 2013-04-12 03:58:14 Re: Add regression tests for COLLATE