Re: proposal: change behavior on collation version mismatch

On Mon, Nov 27, 2023 at 9:30 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Mon, 2023-11-27 at 11:06 -0800, Jeremy Schneider wrote:
> > If we want to have a GUC that
> > allows warning behavior, I think that's OK but I think it should be
> > superuser-only and documented as a "developer" setting similar to
> > zero_damaged_pages.
>
> A GUC seems sensible to express the availability-vs-safety trade-off. I
> suspect we can get a GUC that defaults to "warning" committed, but
> anything else will be controversial.

A guc like this would bring a set of problems similar to what we have
e.g. with fsync.

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. Sure, people shouldn't do that - but people will, and it will
make things harder to debug.

There's been talk before about adding a "tainted" flag or similar to
pg_control that gets set if you ever start the system with fsync=off.
Similar things could be done here of course, but I'd worry a bit about
adding another flag like this which can lead to
hard-to-determine-state without resolving that.

(The fact that we have "fsync" under WAL config and not developer
options is an indication that we can't really use the classification
of the config parameters are a good indicator of what's safe and not
safe to set)

I could get behind turning it into an error though :)

//Magnus