Hi,
On 2021-04-20 12:05:27 +1200, Thomas Munro wrote:
> I'll hold off reverting for a few more days to see if anyone has any
> other thoughts on that, because there doesn't seem to be any advantage
> in being too hasty about it.
I'm not really convinced that this is warranted, and that it isn't
better addressed by reducing the scope of the feature:
When using index collation versions to decide whether to reindex
individual indexes it is important to not have any false negatives -
otherwise the feature could trigger corruption.
However, the feature has a second, IMO more crucial, aspect: Preventing
silent corruption due to collation changes. There are regular reports of
people corrupting their indexes (and subsequently constraints) due to
collation changes (or collation differences between primary/replica).
To be effective detecting such cases it is not required to catch 100% of
all dangerous cases, just that a high fraction of cases is caught.
And handling the composite type case doesn't seem like it'd impact the
percentage of detected collation issues all that much. For one, indexes
on composite types aren't all that common, and additing new columns to
those composite types is likely even rarer. For another, I'd expect that
nearly all databases that have indexes on composite types also have
indexes on non-composite text columns - which'd be likely to catch the
issue.
Given that this is a regularly occurring source of corruption for users,
and not one just negligent operators run into (we want people to upgrade
OS versions), I think we ought to factor that into our decision what to
do.
Greetings,
Andres Freund
