Horton

Re: Collation version tracking for macOS

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: vignesh C <vignesh21@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Joe Conway <mail@joeconway.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Jeremy Schneider <schneider@ardentperf.com>, Peter Geoghegan <pg@bowt.ie>, "Nasby, Jim" <nasbyj@amazon.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-02-13T06:13:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix copy&paste typo in comment

On Tue, Feb 13, 2024 at 1:55 AM Jeff Davis <pgsql@j-davis.com> wrote:
> Postgres can and does latch on to the version of ICU it was compiled
> against. It's a normal shared library dependency.
>
> The problem is that databases -- and the file structures -- outlive a
> particular version of Postgres. So if Postgres 16 is compiled against
> ICU X and Postgres 17 is compiled against ICU Y, how do you upgrade
> from 16 to 17? Postgres 17 will try to access the old file structures
> using ICU Y, and they'll be corrupt.
>
> What we want is the file structures that depend on ICU X to continue to
> find ICU X even after you upgrade to Postgres 17, yet allow new
> structures to be created using ICU Y. In other words, "multi-lib",
> meaning that the same Postgres binary is linking to multiple versions
> of ICU and the different versions for different structures. That would
> allow users to recreate one index at a time to use ICU Y, until nothing
> depends on ICU X any longer.

Ah, I see. At least, I think I do. I think some of this material could
be very usefully included into the first section of the doc you're
trying to write. What you say here makes it a lot easier to grasp the
motivation and use case for this code, at least for me.

-- 
Robert Haas
EDB: http://www.enterprisedb.com