Re: proposal: change behavior on collation version mismatch - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: proposal: change behavior on collation version mismatch
Date
Msg-id 27955d85f65ee64e83b2ade8c50e55d3f53695c0.camel@j-davis.com
Whole thread Raw
In response to Re: proposal: change behavior on collation version mismatch  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, 2023-11-27 at 22:37 +0100, Magnus Hagander wrote:
> That is, set it to "warnings only", insert a single row into the
> table
> with an "unlucky" key, set it back to "errors always" and you now
> have
> a corrupt database, but your setting reflects that it shouldn't be
> corrupt.

You would be giving the setting too much credit if you assume that
consistently keeping it on "error" is a guarantee against corruption.

It only affects what we do when we detect potential corruption, but our
detection is subject to both false positives and false negatives.

We'd need to document the setting so that users understand the
consequences and limitations.

I won't push strongly for such a setting to exist because I know that
it's far from a complete solution. But I believe it would be sensible
considering that this problem is going to take a while to resolve.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Don't use bms_membership in places where it's not needed
Next
From: Nathan Bossart
Date:
Subject: Re: autovectorize page checksum code included elsewhere