(auto)vacuum truncate exclusive lock

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: (auto)vacuum truncate exclusive lock
Date: 2013-04-11 06:45:35
Message-ID: CAMkU=1xYXOJp=jLAASPdSAqab-HwhA_tnRhy+JUe=4=b=v3KoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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've attached a patch that changes that. I also log the number of pages
truncated at the time it gave up, as it would be nice to know if it is
completely starving or making some progress.

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. Is there a way to
have the autoanalyze happen, but then still arrange for the autovacuum to
be triggered again next naptime?

Cheers,

Jeff

Attachment Content-Type Size
autovac_truncate.patch text/x-patch 3.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-04-11 07:09:01 Re: Inconsistent DB data in Streaming Replication
Previous Message Pavel Golub 2013-04-11 05:58:35 Re: [GSOC] questions about idea "rewrite pg_dump as library"