(auto)vacuum truncate exclusive lock

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема (auto)vacuum truncate exclusive lock
Дата
Msg-id CAMkU=1xsLwgLXMKABD5cRhxXh=C9gui99nZzcc09-OHmLv8cdw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: (auto)vacuum truncate exclusive lock  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
On Thursday, April 11, 2013, Tom Lane wrote:
Jeff Janes <jeff.janes@gmail.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

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add regression tests for COLLATE
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: Inconsistent DB data in Streaming Replication