Changing the autovacuum launcher scheduling; oldest table first algorithm

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Subject: Changing the autovacuum launcher scheduling; oldest table first algorithm
Date: 2018-02-28 09:04:27
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers


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.



Masahiko Sawada
NTT Open Source Software Center

Attachment Content-Type Size
autovacuum_scheduling.patch application/octet-stream 16.4 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-02-28 09:10:38 Re: inserts into partitioned table may cause crash
Previous Message Amit Langote 2018-02-28 08:36:56 inserts into partitioned table may cause crash