Re: bumping HASH_VERSION to 3

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bumping HASH_VERSION to 3
Date: 2017-05-15 04:08:37
Message-ID: 20170515040837.GR843225@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 10, 2017 at 11:25:22AM +0530, Amit Kapila wrote:
> On Tue, Apr 11, 2017 at 11:53 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Fri, Mar 31, 2017 at 02:48:05PM -0400, Tom Lane wrote:
> >> +1, as long as we're clear on what will happen when pg_upgrade'ing
> >> an installation containing hash indexes. I think a minimum requirement is
> >> that it succeed and be able to start up, and allow the user to manually
> >> REINDEX such indexes afterwards. Bonus points for:
> >>
> >> 1. teaching pg_upgrade to create a script containing the required REINDEX
> >> commands. (I think it's produced scripts for similar requirements in the
> >> past.)
> >>
> >> 2. marking the index invalid so that the system would silently ignore it
> >> until it's been reindexed. I think there might be adequate infrastructure
> >> for that already thanks to REINDEX CONCURRENTLY, and it'd just be a matter
> >> of getting pg_upgrade to hack the indexes' catalog state. (If not, it's
> >> probably not worth the trouble.)
> >
> > We already have code to do all of that, but it was removed from
> > pg_upgrade in 9.5. You can still see it in 9.4:
> >
> > contrib/pg_upgrade/version_old_8_3.c::old_8_3_invalidate_hash_gin_indexes()
> >
>
> Thanks for the pointer.
>
> > I would be happy to restore that code and make it work for PG 10.
> >
>
> Attached patch implements the two points suggested by Tom. I will add
> this to PG-10 open issues list so that we don't forget about this
> work, let me know if you think otherwise.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Robert,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.

[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-05-15 05:02:28 Typos in pg_basebackup.c
Previous Message Noah Misch 2017-05-15 04:03:15 Re: Removal of plaintext password type references