Re: xid wraparound danger due to INDEX_CLEANUP false

From: Andres Freund <andres(at)anarazel(dot)de>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, masahiko(dot)sawada(at)2ndquadrant(dot)com
Subject: Re: xid wraparound danger due to INDEX_CLEANUP false
Date: 2020-04-16 17:58:46
Message-ID: 20200416175846.av6bnq7bh6jsyn57@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-04-16 16:30:02 +0900, Masahiko Sawada wrote:
> For btree indexes, IIRC skipping index cleanup could not be a cause of
> corruption, but be a cause of index bloat since it leaves recyclable
> pages which are not marked as recyclable. The index bloat is the main
> side effect of skipping index cleanup. When user executes VACUUM with
> INDEX_CLEANUP to reclaim index garbage, such pages will also be
> recycled sooner or later? Or skipping index cleanup can be a cause of
> recyclable page never being recycled?

Well, it depends on what you define as "never". Once the xids on the
pages have wrapped around, the page level xids will appear to be from
the future for a long time. And the metapage xid appearing to be from
the future will prevent some vacuums from actually doing the scan too,
even if INDEX_CLEANUP is reenabled. So a VACUUM, even with
INDEX_CLEANUP on, will not be able to recycle those pages anymore. At
some point the wrapped around xids will be "current" again, if there's
enough new xids.

It's no ok for vacuumlazy.c to make decisions like this. I think the
INDEX_CLEANUP logic clearly needs to be pushed down into the
amvacuumcleanup callbacks, and it needs to be left to the index AMs to
decide what the correct behaviour is.

You can't just change things like this without reviewing the
consequences to AMs and documenting them?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-04-16 18:00:23 Re: Race condition in SyncRepGetSyncStandbysPriority
Previous Message Thomas Munro 2020-04-16 17:56:58 Re: Should we add xid_current() or a int8->xid cast?