Re: Collation version tracking for macOS - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Collation version tracking for macOS
Date
Msg-id CA+Tgmob4vy_5+XcvmY=zDnBe6kp-7n540429EUAGiRy7m+Dgjg@mail.gmail.com
Whole thread Raw
In response to Re: Collation version tracking for macOS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Collation version tracking for macOS
List pgsql-hackers
On Tue, Jun 7, 2022 at 3:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No, I quite agree that we have a problem.  What I don't agree is that
> issuing a lot of false-positive warnings is a solution.  That will
> just condition people to ignore the warnings, and then when their
> platform really does change behavior, they're still screwed.  If we
> could *accurately* report collation behavioral changes, I'd be all
> for that.

I mean, how many false-positive warnings do you think we'll get?

I would argue that if we put out something that's wrong half the time
-- it tells you about all the real problems and an equal number of
imaginary ones -- we'd be way ahead of where we are right now.  If on
the other hand we put out something that's wrong 99% of the time -- it
tells you about all the real problems and ninety-nine times as many
imaginary ones -- that's worse than useless.

There can be some weasel wording in the language e.g. "WARNING:  glibc
has been updated, collation definitions may have changed". It's worth
keeping in mind that the user doesn't necessarily have another source
of information that is more accurate than what we're providing. If
they REINDEX somewhat more often than is really necessary, that may be
painful, but it can still be a lot better than having queries return
wrong answers. If it's not, nobody's forcing them to issue that
REINDEX command.

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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Collation version tracking for macOS
Next
From: vignesh C
Date:
Subject: Re: Handle infinite recursion in logical replication setup