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
