Re: xid wraparound danger due to INDEX_CLEANUP false

From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
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-06-27 05:14:28
Message-ID: CA+fd4k7QZtugGY4H_pUMy7-Pg2-7KLGQCHPfnmtjwCJK2+PCEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 27 Jun 2020 at 08:00, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Fri, Jun 26, 2020 at 5:39 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > My opinion is that there's no need to change the code in the
> > back-branches, and that I don't really like the approach in master
> > either.
>
> I guess it's hard to see a way that we could fix this in the
> backbranches, provided we aren't willing to tolerate a big refactor,
> or a cleanup scan of the index (note that I mean btvacuumcleanup(),
> not btvacuumscan(), which is quite different).

Agreed.

>
> > I think what we're saying is that there is no worse consequence to
> > turning off index_cleanup than some bloat that isn't likely to be
> > recovered unless you REINDEX.
>
> That's true.

Regarding to the extent of the impact, this bug will affect the user
who turned vacuum_index_cleanup off or executed manually vacuum with
INDEX_CLEANUP off for a long time, after some vacuums. On the other
hand, the user who uses INDEX_CLEANUP off on the spot or turns
vacuum_index_cleanup off of the table from the start would not be
affected or less affected.

>
> > In retrospect, I regret committing this patch without better
> > understanding the issues in this area. That was a fail on my part. At
> > the same time, it doesn't really sound like the issues are all that
> > bad. The potential index bloat does suck, but it can still suck less
> > than the alternatives, and we have evidence that for at least one
> > user, it was worth a major version upgrade just to replace the
> > suckitude they had with the suckitude this patch creates.
>
> I actually agree -- this is a really important feature, and I'm glad
> that we have it. Even in this slightly flawed form. I remember a great
> need for the feature back when I was involved in supporting Postgres
> in production.

I apologize for writing this patch without enough consideration. I
should have been more careful as I learned the nbtree page recycle
strategy when discussing vacuum_cleanup_index_scale_factor patch.

Regards,

--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-06-27 05:22:49 Re: Remove a redundant condition check
Previous Message Bharath Rupireddy 2020-06-27 03:53:24 Re: [PATCH] Remove Extra palloc Of raw_buf For Binary Format In COPY FROM