On Mon, 2023-11-27 at 11:06 -0800, Jeremy Schneider wrote:
> I've been tracking the discussions around collation here on the lists
> and I've had a number of conversations with folks working deeply in
> this
> area inside and outside of AWS, and I was part of the effort to
> address
> it at AWS since we first became aware of it many years ago.
For the record, I don't have a strong opinion on your specific
proposals. Not because I don't care, but because the available options
all seem pretty bad -- including the status quo.
My general opinion (not tied specifically to your proposals) is that we
need to pursue a lot of different approaches and hope to mitigate the
problem. With that in mind, I think your proposals have merit but we of
course need to consider the downsides.
> 2) "most users would rather have ease-of-use than 100% safety, since
> it's uncommon"
>
> And I think this led to the current behavior of issuing a warning
> rather
> than an error
The elevel trade-off is *availability* vs safety, not ease-of-use vs
safety. It's harder to reason about what most users might want in that
situation.
> First: I'd suggest that a collation version mismatch should cause an
> ERROR rather than a WARNING by default.
Is this proposal based on our current notion of collation version?
There's been a lot of reasonable skepticism that what's stored in
datcollversion is a good indicator.
> 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.
Regards,
Jeff Davis