Re: [HACKERS] GUC for cleanup indexes threshold.

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: [HACKERS] GUC for cleanup indexes threshold.
Дата
Msg-id CAH2-Wznft2DDntOp_5Zdz_CBHmZf2oeWR-PCHXrYBP9zAof4kQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GUC for cleanup indexes threshold.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] GUC for cleanup indexes threshold.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Mar 21, 2017 at 12:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Wouldn't it break on-disk compatibility with existing btree indexes?

Yes, it would, but see my later remarks on pd_prune_xid. I think that
that would be safe.

> I think we're still trying to solve a problem that Simon postulated in
> advance of evidence that shows how much of a problem it actually is.

I don't think we're still doing that. I think we're discussing the
risk of recycling being broken indefinitely when it doesn't happen in
time.

> Not only might that be unnecessary, but if we don't have a test
> demonstrating the problem, we also don't have a test demonstrating
> that a given approach fixes it.

Preventing recycling from happening until we feel like it is probably
fine. It is not fine to break it forever, though. The specific problem
is that there is an XID stored in dead B-Tree + SP-GiST pages that is
used in the subsequent RecentGlobalXmin interlock that determines if
recycling is safe (if there is no possible index scan that could land
on the dead page). You know, the _bt_page_recyclable() check.

-- 
Peter Geoghegan



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

Предыдущее
От: Michael Banck
Дата:
Сообщение: Re: [HACKERS] Create replication slot in pg_basebackup if requestedand not yet present
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)