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 |
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" |