Re: REINDEX vs broken HOT chains, redux
От | Tom Lane |
---|---|
Тема | Re: REINDEX vs broken HOT chains, redux |
Дата | |
Msg-id | 5690.1303233166@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: REINDEX vs broken HOT chains, redux (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: REINDEX vs broken HOT chains, redux
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.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? 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. regards, tom lane
В списке pgsql-hackers по дате отправления: