(auto)vacuum truncate exclusive lock

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема (auto)vacuum truncate exclusive lock
Дата
Msg-id CAMkU=1xYXOJp=jLAASPdSAqab-HwhA_tnRhy+JUe=4=b=v3KoQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: (auto)vacuum truncate exclusive lock  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: (auto)vacuum truncate exclusive lock  (Kevin Grittner <kgrittn@ymail.com>)
Список 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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Golub
Дата:
Сообщение: Re: [GSOC] questions about idea "rewrite pg_dump as library"
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Inconsistent DB data in Streaming Replication