Re: Add parallelism and glibc dependent only options to reindexdb
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>, Daniel Verite <daniel@manitou-mail.org>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kevin Grittner <kgrittn@gmail.com>
Date: 2019-07-08T07:57:40Z
Lists: pgsql-hackers
On Fri, Jul 05, 2019 at 07:25:41PM +0200, Julien Rouhaud wrote: > On Fri, Jul 5, 2019 at 6:16 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: >> Isn't that also the case for your proposal? We are not going to release >> a new reindexdb before a new REINDEX. > > Sure, but my point was that once the new reindexdb is released (or if > you're so desperate, using a nightly build or compiling your own), it > can be used against any previous major version. There is probably a > large fraction of users who don't perform a postgres upgrade when they > upgrade their OS, so that's IMHO also something to consider. I think that we need to think long-term here and be confident in the fact we will still see breakages with collations and glibc, using a solution that we think is the right API. Peter's idea to make the backend-aware command of the filtering is cool. On top of that, there is no need to add any conflict logic in reindexdb and we can live with restricting --jobs support for non-index objects. -- Michael
Commits
-
Add support for --jobs in reindexdb
- 5ab892c391c6 13.0 landed
-
Remove more progname references in vacuumdb.c
- 3cae75f4209b 13.0 landed
-
Refactor parallelization processing code in src/bin/scripts/
- 5f3840370b63 13.0 landed