Re: Change initdb default to the builtin collation provider - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Change initdb default to the builtin collation provider
Date
Msg-id deb797b6766db4fd992454c28d36ba227451493e.camel@j-davis.com
Whole thread Raw
In response to Re: Change initdb default to the builtin collation provider  (Laurenz Albe <laurenz.albe@cybertec.at>)
List 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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH v1] command_tag_format — protocol-level command tag negotiation via _pq_
Next
From: Masahiko Sawada
Date:
Subject: Re: tid_blockno() and tid_offset() accessor functions