Re: bumping HASH_VERSION to 3

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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?

+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.)

A variant on that might just be to not transfer over hash indexes,
leaving the user to CREATE them rather than REINDEX them.

regards, tom lane