Re: bumping HASH_VERSION to 3

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bumping HASH_VERSION to 3
Date: 2017-03-31 18:19:53
Message-ID: CABUevEzPBJdvXS4Qv9aM8d07c1Q_5XBKBw94z-4138hyJWJ7Og@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 31, 2017 at 8:17 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> Starting a new thread about this to get more visibility.
>
> Despite the extensive work that has been done on hash indexes this
> release, we have thus far not made any change to the on-disk format
> that is not nominally backward-compatible. Commit
> 293e24e507838733aba4748b514536af2d39d7f2 did make a change for new
> hash indexes, but included backward-compatibility code so that old
> indexes would continue to work. However, I'd like to also commit
> Mithun Cy's patch to expand hash indexes more gradually -- latest
> version in http://postgr.es/m/CAD__OujD-iBxm91ZcqziaYftWqJxnFqgMv361V9
> zke83s6ifBg(at)mail(dot)gmail(dot)com
> -- and that's not backward-compatible.
>
> It would be possible to write code to convert the old metapage format
> to the new metapage format introduced by that patch, and it wouldn't
> be very hard, but I think it would be better to NOT do that, and
> instead force everybody upgrading to v10 to rebuild all of their hash
> indexes. If we don't do that, then we'll never know whether
> instances of hash index corruption reported against v10 or higher are
> caused by defects in the new code, because there's always the chance
> that the hash index could have been built on a pre-v10 version, got
> corrupted because of the lack of WAL-logging, and then been brought up
> to v10+ via pg_upgrade. Forcing a reindex in v10 kills three birds
> with one stone:
>
> - No old, not logged, possibly corrupt hash indexes floating around
> after an upgrade to v10.
> - Can remove the backward-compatibility code added by
> 293e24e507838733aba4748b514536af2d39d7f2 instead of keeping it around
> forever.
> - No need to worry about doing an in-place upgrade of the metapage for
> the above-mentioned patch.
>
> Thoughts?
>

Given the state of hash indexes in <= 9.6, I think this is a reasonable
tradeoff. Most people won't be using them at all today. Those that do will
have to "pay" with a REINDEX on upgrade. I think the benefits definitely
outweigh the cost.

So +1 for doing it.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Feike Steenbergen 2017-03-31 18:21:23 [BUGS] BUG #14600: Passwords in user mappings leaked by psql \deu+ command
Previous Message Kevin Grittner 2017-03-31 18:18:52 Re: delta relations in AFTER triggers