Re: REINDEX CONCURRENTLY 2.0
Robert Treat <rob@xzilla.net>
From: Robert Treat <rob@xzilla.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Sergei Kornilov <sk@zsrv.org>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-29T15:47:10Z
Lists: pgsql-hackers
On Fri, Mar 29, 2019 at 3:28 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 2019-03-28 09:07, Sergei Kornilov wrote: > > Unfortunately patch does not apply due recent commits. Any chance this can be fixed (and even committed in pg12)? > > Committed :) > Given this has been committed I've probably missed the window, but philosophically speaking, is there any reason not to make the "concurrently" behavior the default behavior, and require a keyword for the more heavy-weight old behavior? In most production scenarios you probably want to avoid exclusive locking, and in the cases where that isn't an issue, 'concurrently' isn't that much slower that most users would object to it. I would perhaps give a nod to historical syntax concerns, but this would more closely align with the behavior in vacuum vs vacuum full, and we've done behavior modifying changes such as the recent WITH ... MATERIALIZED change. Thoughts? Robert Treat https://xzilla.net
Commits
-
Prevent reindex of invalid indexes on TOAST tables
- 8bca5f93547c 12.3 landed
- 61d7c7bce368 13.0 landed
-
Rework handling of invalid indexes with REINDEX CONCURRENTLY
- a6dcf9df4d91 12.0 landed
-
Split builtins.h to a new header ruleutils.h
- 7b1c2a0f2066 9.5.0 cited