| From: | Tobias Bussmann <t(dot)bussmann(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Collation version tracking for macOS |
| Date: | 2022-06-10 01:45:19 |
| Message-ID: | 59782113-8CE1-422C-88CA-961BE6733DC1@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Am 08.06.2022 um 16:16 schrieb Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> The proposed patch would result in a warning about every collation-
> sensitive index during every macOS major version upgrade, ie about
> once a year for most people.
> We need something that has at least *some* connection to actual changes.
In Postgres.app we introduced default collation versioning and warnings about possible mismatches from outside the actual server. When the user runs initdb with the GUI wrapper, the OS version and a checksum of the LC_COLLATE file of the used default collation is stored as meta-data. This allows to display a reindex warning on startup if the hash changes or we hardcode a known incompatible OS change.
Having collversion support on macOS within postgres would leverage the existing infrastructure for version change warnings and enables support for multiple collations. But I agree, we need something more specific than the major OS version here. Lacking any collation version information from the provider, a checksum on the binary LC_COLLATE file is the best I can come up with.
Best regards,
Tobias
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2022-06-10 01:47:54 | Re: Collation version tracking for macOS |
| Previous Message | Thomas Munro | 2022-06-10 01:22:32 | Re: Collation version tracking for macOS |