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

From Jeff Janes
Subject (auto)vacuum truncate exclusive lock
Date
Msg-id CAMkU=1xYXOJp=jLAASPdSAqab-HwhA_tnRhy+JUe=4=b=v3KoQ@mail.gmail.com
Whole thread Raw
Responses Re: (auto)vacuum truncate exclusive lock
Re: (auto)vacuum truncate exclusive lock
List 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

pgsql-hackers by date:

Previous
From: Pavel Golub
Date:
Subject: Re: [GSOC] questions about idea "rewrite pg_dump as library"
Next
From: Amit Kapila
Date:
Subject: Re: Inconsistent DB data in Streaming Replication