On Sat, 27 Jun 2020 at 08:00, Peter Geoghegan <p...@bowt.ie> wrote: > > On Fri, Jun 26, 2020 at 5:39 AM Robert Haas <robertmh...@gmail.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
