From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Subject: | Re: Add parallelism and glibc dependent only options to reindexdb |
Date: | 2019-07-02 10:12:40 |
Message-ID: | 20190702101240.dipk7wphmsoitlw3@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 02, 2019 at 10:45:44AM +0200, Julien Rouhaud wrote:
>On Tue, Jul 2, 2019 at 10:28 AM Tomas Vondra
><tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>>
>> I wonder why this is necessary:
>>
>> pg_log_error("cannot reindex glibc dependent objects and a subset of objects");
>>
>> What's the reasoning behind that? It seems like a valid use case to me -
>> imagine you have a bug database, but only a couple of tables are used by
>> the application regularly (the rest may be archive tables, for example).
>> Why not to allow rebuilding glibc-dependent indexes on the used tables, so
>> that the database can be opened for users sooner.
>
>It just seemed wrong to me to allow a partial processing for something
>that's aimed to prevent corruption. I'd think that if users are
>knowledgeable enough to only reindex a subset of indexes/tables in
>such cases, they can also discard indexes that don't get affected by a
>collation lib upgrade. I'm not strongly opposed to supporting if
>though, as there indeed can be valid use cases.
>
I don't know, it just seems like an unnecessary limitation.
>> BTW now that we allow rebuilding only some of the indexes, it'd be great
>> to have a dry-run mode, were we just print which indexes will be rebuilt
>> without actually rebuilding them.
>
>+1. If we end up doing the filter in the backend, we'd have to add
>such option in the REINDEX command, and actually issue all the orders
>to retrieve the list.
Hmmm, yeah. FWIW I'm not requesting v0 to have that feature, but it'd be
good to design the feature in a way that allows adding it later.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2019-07-02 10:15:50 | Re: pg_waldump and PREPARE |
Previous Message | Amit Langote | 2019-07-02 09:28:58 | d25ea01275 and partitionwise join |