Re: REINDEX vs broken HOT chains, redux

Excerpts from Tom Lane's message of mar abr 19 14:12:46 -0300 2011:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Excerpts from Tom Lane's message of mar abr 19 12:29:04 -0300 2011:
> >> I'm intending to revert last week's patch in favor of this approach,
> >> at least in HEAD. It'll be slightly more invasive than the previous
> >> patch because of the API change for index_build, so I'm not sure whether
> >> to back-patch or not --- comments?
>
> > Maybe add a new function index_build_ext that has the API change, and
> > keep the existing index_build as a wrapper that keeps the current
> > behavior. In HEAD just change the API of index_build and make
> > index_build_ext a macro on top of the function (or just make it
> > disappear.)
>
> Not sure it's worth that amount of trouble. index_build is pretty far
> down in the nest of code that manages index (re)building --- is it at
> all likely that third-party code is calling it directly?

Then why bother keeping the API unchanged? If you're correct, it would
be pointless.

> And even more to the point, if there is such third-party code, we don't
> want the fix to fail to operate when a reindex is invoked through that
> code path rather than the core paths. So if you think there's a
> realistic risk of this, we probably shouldn't back-patch.

After actually having a look at the API, I don't.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support