| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Change initdb default to the builtin collation provider |
| Date: | 2026-03-11 21:43:11 |
| Message-ID: | deb797b6766db4fd992454c28d36ba227451493e.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2026-03-11 at 21:05 +0100, Laurenz Albe wrote:
> The big advantage: if you have only two or three indexes in your
> database that are sorted in a collation other than C, the likelihood
> for index corruption will be way lower. For example, the unique
> constraint on your part number column that contains values like
> 'XY-1-13*' or '*P1-12_A' (which are pretty likely to be affected by
> the subtle changes in libc collations) will be sorted in the C
> collation, which is just fine for everybody.
Agreed. The collation problems are not because it's used in the handful
of indexes where it's useful; the problems happen when it's used
everywhere.
If a collation version change is detected, and a few indexes need to be
REINDEXed, I think users understand that. But it's pretty difficult to
explain to a user that all text indexes (including primary keys) need
to be reindexed, and that there's no way to keep track of what still
needs to be done.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-03-11 21:48:08 | Re: tid_blockno() and tid_offset() accessor functions |
| Previous Message | Andres Freund | 2026-03-11 21:39:04 | Re: [PATCH v1] command_tag_format — protocol-level command tag negotiation via _pq_ |