Re: GiST VACUUM

Поиск
Список
Период
Сортировка
Искать
От
Heikki Linnakangas
Тема
Re: GiST VACUUM
Дата
Msg-id
5f7ed675-d1fc-66ef-f316-645080ff9625@iki.fi
Ответ на
Re: GiST VACUUM (Andrey Borodin)
Список
Дерево обсуждения
GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Thomas Munro <thomas.munro@enterprisedb.com>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Heikki Linnakangas <hlinnaka@iki.fi>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Heikki Linnakangas <hlinnaka@iki.fi>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
Re: GiST VACUUM Andrey Borodin <x4mmm@yandex-team.ru>
On 24/03/2019 18:50, Andrey Borodin wrote:
> I was working on new version of gist check in amcheck and understand one more thing:
> 
> /* Can this page be recycled yet? */
> bool
> gistPageRecyclable(Page page)
> {
>      return PageIsNew(page) ||
>          (GistPageIsDeleted(page) &&
>           TransactionIdPrecedes(GistPageGetDeleteXid(page), RecentGlobalXmin));
> }
> 
> Here RecentGlobalXmin can wraparound and page will become unrecyclable for half of xid cycle. Can we prevent it by resetting PageDeleteXid to InvalidTransactionId before doing RecordFreeIndexPage()?
> (Seems like same applies to GIN...)

True, and B-tree has the same issue. I thought I saw a comment somewhere 
in the B-tree code about that earlier, but now I can't find it. I 
must've imagined it.

We could reset it, but that would require dirtying the page. That would 
be just extra I/O overhead, if the page gets reused before XID 
wraparound. We could avoid that if we stored the full XID+epoch, not 
just XID. I think we should do that in GiST, at least, where this is 
new. In the B-tree, it would require some extra code to deal with 
backwards-compatibility, but maybe it would be worth it even there.

- Heikki

В списке pgsql-hackers по дате отправления
От: Daniel Gustafsson
Дата:
От: Lucas Viecelli
Дата:
FAQ