Re: xid wraparound danger due to INDEX_CLEANUP false

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: xid wraparound danger due to INDEX_CLEANUP false
Дата
Msg-id CAH2-Wz=gMdoa8eXs_mSr3ucsOpdVDCzJQuhLUTgdg80wgUE9qQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: xid wraparound danger due to INDEX_CLEANUP false  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: PG 13 release notes, first draft
Следующее
От: Ashwin Agrawal
Дата:
Сообщение: pg_basebackup misses to report checksum error