On Wed, Jun 8, 2022 at 10:24 PM Jeremy Schneider
<schneider@ardentperf.com> wrote:
> Even if PG supports two versions of ICU, how does someone actually go about removing every dependency on the old
versionand replacing it with the new?
They simply REINDEX, without changing anything. The details are still
fuzzy, but at least that's what I was thinking of.
This should be possible by generalizing the definition of a collation
to recognize that different ICU versions can support the same
collation. Of course we'd also have to remember which actual ICU
version and specific "physical collation" was currently in use by each
index. We'd also probably have to have some policy about which ICU
version was the latest (or some suitably generalized version of that
that applies to collation providers more generally).
> Can it be done without downtime? Can it be done without modifying a running application?
Clearly the only way that we can ever transition to a new "physical
collation" is by reindexing using a newer ICU version. And clearly
there is going to be a need to fully deprecate any legacy version of
ICU on a long enough timeline. There is just no getting around that.
The advantage of an approach along the lines that I've laid out is
that everything can be done incrementally, possibly some time after an
initial OS or Posgres upgrade, once everything has settled. Much much
later, even. If the same new ICU version isn't available in your
original/old environment (which is likely), you can avoid reindexing,
and so reserve the option of backing out of a complex upgrade until
very late in the process. You're going to have to do it eventually,
but it can probably just be an afterthought.
--
Peter Geoghegan
