| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: xid wraparound danger due to INDEX_CLEANUP false |
| Date: | 2020-05-06 19:04:49 |
| Message-ID: | CAH2-Wz=RGBpg9zTe3eaa12UkAYkon8qv8d82HEPx=gmDdsB=4Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 6, 2020 at 11:28 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> This approach has an obvious disadvantage: the patch really has to
> teach *every* index AM to do something with that state (most will
> simply do no work). It seems logical to have the index AM control what
> happens, though. This allows the logic to live inside
> _bt_vacuum_needs_cleanup() in the case of nbtree, so there is only one
> place where we make decisions like this.
Also, do we really want to skip summarization of BRIN indexes? This
cleanup is rather dissimilar to the cleanup that takes place in most
other AMs -- it isn't really that related to garbage collection (BRIN
is rather unique in this respect). I think that BRIN might be an
inappropriate target for "index_cleanup off" VACUUMs for that reason.
See the explanation of how this takes place from the docs:
https://www.postgresql.org/docs/devel/brin-intro.html#BRIN-OPERATION
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-05-06 19:24:40 | Re: do {} while (0) nitpick |
| Previous Message | Ranier Vilela | 2020-05-06 18:58:15 | Re: Postgres Windows build system doesn't work with python installed in Program Files |