Re: Avoid endless futile table locks in vacuuming.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Avoid endless futile table locks in vacuuming.
Дата
Msg-id 2788.1451241191@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Avoid endless futile table locks in vacuuming.  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Avoid endless futile table locks in vacuuming.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> If a partially-active table develops a slug of stable all-visible,
> non-empty pages at the end of it, then every autovacuum of that table
> will skip the end pages on the forward scan, think they might be
> truncatable, and take the access exclusive lock to do the truncation.
> And then immediately fail when it sees the last page is not empty.
> This can persist for an indefinite number of autovac rounds.

> This is not generally a problem, as the lock is taken conditionally.
> However, the lock is also logged and passed over to any hot standbys,
> where it must be replayed unconditionally.  This can cause query
> cancellations.

> The simple solution is to always scan the last page of a table, so it
> can be noticed that it is not empty and avoid the truncation attempt.

This seems like a reasonable proposal, but I find your implementation
unconvincing: there are two places in lazy_scan_heap() that pay attention
to scan_all, and you touched only one of them.  Thus, if we fail to
acquire cleanup lock on the table's last page on the first try, the
change is for naught.  Shouldn't we be insisting on getting that lock?
Or, if you intentionally didn't change that because it seems like too
high a price to pay, why doesn't the comment reflect that?
        regards, tom lane



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

Предыдущее
От: Grzegorz Sampolski
Дата:
Сообщение: Re: pam auth - add rhost item
Следующее
От: Artur Zakirov
Дата:
Сообщение: Re: Fuzzy substring searching with the pg_trgm extension