On Wed, Jun 8, 2022 at 10:24 PM Jeremy Schneider <schnei...@ardentperf.com> wrote: > Even if PG supports two versions of ICU, how does someone actually go about > removing every dependency on the old version and 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
