pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Kevin Grittner <kgrittn@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Subject: Re: Add parallelism and glibc dependent only options to reindexdb
Date: Tue, 2 Jul 2019 12:12:40 +0200
Message-ID: <20190702101240.dipk7wphmsoitlw3@development> (raw)
In-Reply-To: <CAOBaU_ZuVqBr1BLrEDLRt1Bp_aF_F9ShM+uy=ePLWm9L9cnDYw@mail.gmail.com>
References: <CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com>
	<20190702082804.e7qgfncsyvxpcgra@development>
	<CAOBaU_ZuVqBr1BLrEDLRt1Bp_aF_F9ShM+uy=ePLWm9L9cnDYw@mail.gmail.com>

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.vondra@2ndquadrant.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






view thread (78+ messages)  latest in thread

Message-ID: <20190702101240.dipk7wphmsoitlw3@development>
Permalink:  ../20190702101240.dipk7wphmsoitlw3@development/
Also on:    postgresql.org/message-id/20190702101240.dipk7wphmsoitlw3@development

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, rjuju123@gmail.com, pgsql-hackers@lists.postgresql.org, kgrittn@gmail.com, michael@paquier.xyz
  Subject: Re: Add parallelism and glibc dependent only options to reindexdb
  In-Reply-To: <20190702101240.dipk7wphmsoitlw3@development>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox