Re: REINDEX backend filtering

From: Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REINDEX backend filtering
Date: 2021-02-24 18:34:59
Message-ID: CAC8Q8tJ5k=nsVXWF+PzG93Q3sEYdunMw1Rgy9LbvvUabY+_QSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

The PostGIS project needed this from time to time. Would be great if
reindex by opclass can be made possible.

We changed the semantics of btree at least twice (in 2.4 and 3.0), fixed
some ND mixed-dimension indexes semantics in 3.0, fixed hash index on 32
bit arch in 3.0.

On Thu, Dec 3, 2020 at 12:32 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> Hello,
>
> Now that we have the infrastructure to track indexes that might be
> corrupted
> due to changes in collation libraries, I think it would be a good idea to
> offer
> an easy way for users to reindex all indexes that might be corrupted.
>
> I'm attaching a POC patch as a discussion basis. It implements a new
> "COLLATION" option to reindex, with "not_current" being the only accepted
> value. Note that I didn't spent too much efforts on the grammar part yet.
>
> So for instance you can do:
>
> REINDEX (COLLATION 'not_current') DATABASE mydb;
>
> The filter is also implemented so that you could cumulate multiple
> filters, so
> it could be easy to add more filtering, for instance:
>
> REINDEX (COLLATION 'libc', COLLATION 'not_current') DATABASE mydb;
>
> to only rebuild indexes depending on outdated libc collations, or
>
> REINDEX (COLLATION 'libc', VERSION 'X.Y') DATABASE mydb;
>
> to only rebuild indexes depending on a specific version of libc.
>

--
Darafei "Komяpa" Praliaskouski
OSM BY Team - http://openstreetmap.by/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-02-24 18:36:02 Re: REINDEX backend filtering
Previous Message Tom Lane 2021-02-24 17:14:47 Re: Bizarre behavior of \w in a regular expression bracket construct