From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Douglas Doole <dougdoole(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Collation versioning |
Date: | 2019-11-08 04:40:31 |
Message-ID: | 3c3b9ff84d21acf3188558928249d04db84ea2e9.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2019-11-08 at 15:04 +1300, Thomas Munro wrote:
> So we have three proposals:
>
> 1. Assume that pre-13 indexes that depend on collations are
> potentially corrupted and complain until they are reindexed. This
> could be done by having pg_upgrade run ALTER INDEX ... DEPENDS ON
> COLLATION "fr_FR" VERSION '' (empty string, or some other default
> value that we don't think is going to coincide with a real version).
> 2. Assume that pre-13 indexes are not corrupted. In the target 13
> database, the index will be created in the catalogs with the
> provider's current version.
> 3. We don't know if pre-13 indexes are corrupted or not, and we'll
> record that with a special value just as in proposal #1, except that
> we could show a different hint for that special version value. It
> would tell you can you can either REINDEX, or run ALTER INDEX ...
> DEPENDS ON COLLATION "fr_FR" VERSION '34.0' if you believe the index
> to have been created with the current collation version on an older
> release of PostgreSQL that didn't track versions.
I think #1 is bad because it would frighten all users, even those who
didn't upgrade their libc at all, only PostgreSQL. I don't think that
shouting "wolf" for no real reason will improve trust in PostgreSQL.
#2 is bad because it may hide pre-existing index corruption.
#3 is the best proposal, but there is still the need to run
ALTER INDEX on all affected indexes to keep PostgreSQL from nagging.
Perhaps the situation could be improved with a pg_upgrade option
--i-know-my-indexes-are-fine that causes a result like #2.
Together with a bold note in the release notes, this may relieve
the pain.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-11-08 04:43:46 | Re: Remove HeapTuple and Buffer dependency for predicate locking functions |
Previous Message | imai.yoshikazu@fujitsu.com | 2019-11-08 04:35:30 | RE: Planning counters in pg_stat_statements (using pgss_store) |