From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <nasbyj(at)amazon(dot)com> |
Cc: | 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-07 00:25:24 |
Message-ID: | 976279.1654561524@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <nasbyj(at)amazon(dot)com> writes:
>> I think the real problem here is that the underlying software mostly
>> doesn't take this issue seriously.
> The first step to a solution is admitting that the problem exists.
> Ignoring broken backups, segfaults and data corruption as a "rant"
> implies that we simply throw in the towel and tell users to suck it up
> or switch engines. There are other ways to address this short of the
> community doing all the work itself. One simple example would be to
> refuse to start if the collation provider has changed since initdb
> (which we'd need to allow users to override).
You're conveniently skipping over the hard part, which is to tell
whether the collation provider has changed behavior (which we'd better
do with pretty darn high accuracy, if we're going to refuse to start
on the basis of thinking it has). Unfortunately, giving a reliable
indication of collation behavioral changes is *exactly* the thing
that the providers aren't taking seriously.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Schneider | 2022-06-07 00:42:41 | Re: Collation version tracking for macOS |
Previous Message | Ranier Vilela | 2022-06-07 00:14:35 | Re: Reducing Memory Consumption (aset and generation) |