Re: xid wraparound danger due to INDEX_CLEANUP false - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: xid wraparound danger due to INDEX_CLEANUP false
Date
Msg-id CAH2-Wz=gMdoa8eXs_mSr3ucsOpdVDCzJQuhLUTgdg80wgUE9qQ@mail.gmail.com
Whole thread Raw
In response to Re: xid wraparound danger due to INDEX_CLEANUP false  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Wed, May 6, 2020 at 1:06 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Good question.  I agree that BRIN summarization is not at all related to
> what other index AMs do during the cleanup phase.  However, if the
> index_cleanup feature is there to make it faster to process a table
> that's nearing wraparound hazards (or at least the warnings), then I
> think it makes sense to complete the vacuum as fast as possible -- which
> includes not trying to summarize it for brin indexes.

I forgot about the fact that the AutoVacuumRequestWork() interface
exists at all until just now. That's how "autosummarize = on" makes
sure that autosummarization takes place. These work items are not
affected by the fact that the VACUUM happens to be a "index_cleanup
off" VACUUM. Fortunately, the user is required to explicitly opt-in to
autosummarization (by setting "autosummarize = on") in order for
autovacuum to spend extra time processing work items when it might be
important to advance relfrozenxid ASAP. (My initial assumption was
that the autosummarization business happened within
brinvacuumcleanup(), but I now see that I was mistaken.)

There is a separate question (nothing to do with summarization) about
the cleanup steps performed in brinvacuumcleanup(), which are unlike
any of the cleanup/maintenance that we expect for an amvacuumcleanup
routine in general. As I said in my last e-mail, these steps have
nothing to do with garbage tuples. Rather, it's deferred maintenance
that we need to do even with append-only workloads (including when
autosummarization has not been enabled). What about that? Is that
okay?

ISTM that the fundamental issue is that BRIN imagines that it is in
control, which isn't quite true in light of the "index_cleanup off"
stuff -- a call to brinvacuumcleanup() is expected to take place at
fairly consistent intervals to take care of revmap processing, which,
in general, might not happen now. I blame commit a96c41feec6 for this,
not BRIN. ISTM that whatever behavior we deem appropriate, the proper
place to decide on it is within BRIN. Not within vacuumlazy.c.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: PG 13 release notes, first draft
Next
From: Ashwin Agrawal
Date:
Subject: pg_basebackup misses to report checksum error