Re: xid wraparound danger due to INDEX_CLEANUP false

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: xid wraparound danger due to INDEX_CLEANUP false
Дата
Msg-id 20200416175846.av6bnq7bh6jsyn57@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: xid wraparound danger due to INDEX_CLEANUP false  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: xid wraparound danger due to INDEX_CLEANUP false  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Список 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



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Should we add xid_current() or a int8->xid cast?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Race condition in SyncRepGetSyncStandbysPriority