Re: GiST VACUUM

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Костя Кузнецов <chapaev28(at)ya(dot)ru>
Subject: Re: GiST VACUUM
Date: 2019-03-25 13:20:39
Message-ID: 5f7ed675-d1fc-66ef-f316-645080ff9625@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lucas Viecelli 2019-03-25 13:20:54 Re: warning to publication created and wal_level is not set to logical
Previous Message Daniel Gustafsson 2019-03-25 13:18:05 pg_malloc0() instead of pg_malloc()+memset()