Re: Temporary tables prevent autovacuum, leading to XID wraparound

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Temporary tables prevent autovacuum, leading to XID wraparound
Date: 2018-01-25 11:30:09
Message-ID: CAD21AoBQHk2=77dh8CETSbMYqbSkvQbMdc+ZtpeTAJvNfcGmxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 25, 2018 at 3:14 PM, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>
> FIX
> ====================================
>
> I have the following questions. Along which line should I proceed to fix the problem?
>
> * Why does autovacuum launcher always choose only one database when that database need vacuuming for XID wraparound? Shouldn't it also choose other databases?

Yeah, I'd also like to fix this issue. This can be problem even in
other case; there are two databases that require anti-wraparound
vacuum, and one of them has a very large table that could take a long
time to vacuum. In this case, if autovacuum chooses the database
having big table first, another database would not be selected until
an autovacuum worker completes vacuum on the large table. To deal with
it, I think we can make autovacuum workers tell that it is no longer
necessary to launch a new autovacuum worker on the database to
autovacuum launcher before exit. For example, autovacuum worker
reports both the total number of relations and the number of relations
that require an anti-wraparound vacuum to the stats collector.

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2018-01-25 11:40:28 Re: CONSTANT/NOT NULL/initializer properties for plpgsql record variables
Previous Message Etsuro Fujita 2018-01-25 10:03:08 Re: non-bulk inserts and tuple routing