Changing the autovacuum launcher scheduling; oldest table first algorithm

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Changing the autovacuum launcher scheduling; oldest table first algorithm
Дата
Msg-id CAD21AoBUaSRBypA6pd9ZD=U-2TJCHtbyZRmrS91Nq0eVQ0B3BA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Changing the autovacuum launcher scheduling; oldest table firstalgorithm  (Grigory Smolkin <g.smolkin@postgrespro.ru>)
Re: Changing the autovacuum launcher scheduling; oldest table firstalgorithm  (Andres Freund <andres@anarazel.de>)
Re: Changing the autovacuum launcher scheduling; oldest table firstalgorithm  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Hi,

I've created the new thread for the changing AV launcher scheduling.
The problem of AV launcher scheduling is described on [1] but I
summarize it here.

If there is even one database that is at risk of wraparound, currently
AV launcher selects the database having the oldest datfrozenxid until
all tables in that database have been vacuumed. This leads that tables
on other database can bloat and not be frozen because other database
are not selected by AV launcher. It makes things worse if the database
has a large table that takes a long time to be vacuumed.

Attached patch changes the AV launcher scheduling algorithm based on
the proposed idea by Robert so that it selects a database first that
has the oldest table when the database is at risk of wraparound. For
detail of the algorithm please refer to [2].

In this algorithm, the running AV workers advertise the next
datfrozenxid on the shared memory that we will have. That way, AV
launcher can select a database that has the oldest table in the
database cluster. However, this algorithm doesn't support the case
where the age of next datfrozenxid gets greater than
autovacum_vacuum_max_age. This case can happen if users set
autovacvuum_vacuum_max_age to small value and vacuuming the whole
database takes a long time. But since it's not a common case and it
doesn't degrade than current behavior even if this happened, I think
it's not a big problem.

Feedback is very welcome.

[1] https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1F8A4DC6%40G01JPEXMBYT05
[2]
https://www.postgresql.org/message-id/CA%2BTgmobT3m%3D%2BdU5HF3VGVqiZ2O%2Bv6P5wN1Gj%2BPrq%2Bhj7dAm9AQ%40mail.gmail.com

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Вложения

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: inserts into partitioned table may cause crash
Следующее
От: Amit Langote
Дата:
Сообщение: Re: inserts into partitioned table may cause crash