From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com> |
Subject: | Re: Add parallelism and glibc dependent only options to reindexdb |
Date: | 2019-07-08 07:57:40 |
Message-ID: | 20190708075740.GF2709@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2019-07-08 08:04:38 | Re: Implementing Incremental View Maintenance |
Previous Message | Thomas Munro | 2019-07-08 07:56:25 | Re: Replication & recovery_min_apply_delay |