Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers