Re: [HACKERS] GUC for cleanup indexes threshold. - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] GUC for cleanup indexes threshold.
Date
Msg-id CAH2-WznH25+9wVBbHWuc2bidXGV8MpXBHty6Bqo5GXaruje82A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GUC for cleanup indexes threshold.  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] GUC for cleanup indexes threshold.  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Sat, Mar 4, 2017 at 1:30 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> While I can't see this explained anywhere, I'm
>> pretty sure that that's supposed to be impossible, which this patch
>> changes.
>>
>
> What makes you think that patch will allow pg_class.relfrozenxid to be
> advanced past opaque->btpo.xact which was previously not possible?

By not reliably recycling pages in a timely manner, we won't change
anything about the dead page. It just sticks around. This is mostly
fine, but we still need VACUUM to be able to reason about it (to
determine if it is in fact recyclable), which is what I'm concerned
about breaking here. It still needs to be *possible* to recycle any
recyclable page at some point (e.g., when we find it convenient).

pg_class.relfrozenxid is InvalidTransactionId for indexes because
indexes generally don't store XIDs. This is the one exception that I'm
aware of, presumably justified by the fact that it's only for
recyclable pages anyway, and those are currently *guaranteed* to get
recycled quickly. In particular, they're guaranteed to get recycled by
the next VACUUM. They may be recycled in the course of anti-wraparound
VACUUM, even if VACUUM has no garbage tuples to kill (even if we only
do lazy_cleanup_index() instead of lazy_vacuum_index()). This is the
case that this patch proposes to have us skip touching indexes for.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Parallel seq. plan is not coming against inheritance orpartition table
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Logical replication existing data copy