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 10:28:04 +0200
Message-ID: <20190702082804.e7qgfncsyvxpcgra@development> (raw)
In-Reply-To: <CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com>
References: <CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com>

On Sun, Jun 30, 2019 at 11:45:47AM +0200, Julien Rouhaud wrote:
>Hi,
>
>With the glibc 2.28 coming, all users will have to reindex almost
>every indexes after a glibc upgrade to guarantee the lack of
>corruption.  Unfortunately, reindexdb is not ideal for that as it's
>processing everything using a single connexion and isn't able to
>discard indexes that doesn't depend on a glibc collation.
>
>PFA a patchset to add parallelism to reindexdb (reusing the
>infrastructure in vacuumdb with some additions) and an option to
>discard indexes that doesn't depend on glibc (without any specific
>collation filtering or glibc version detection), with updated
>regression tests.  Note that this should be applied on top of the
>existing reindexdb cleanup & refactoring patch
>(https://commitfest.postgresql.org/23/2115/).
>
>This was sponsored by VMware, and has been discussed internally with
>Kevin and Michael, in Cc.

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.

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.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services






view thread (78+ messages)  latest in thread

Message-ID: <20190702082804.e7qgfncsyvxpcgra@development>
Permalink:  ../20190702082804.e7qgfncsyvxpcgra@development/
Also on:    postgresql.org/message-id/20190702082804.e7qgfncsyvxpcgra@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: <20190702082804.e7qgfncsyvxpcgra@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