Re: Bogus collation version recording in recordMultipleDependencies
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Andres Freund <andres@anarazel.de>, Thomas Munro
<thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-05T20:58:08Z
Lists: pgsql-hackers
On 4/21/21 4:28 PM, Andres Freund wrote: > 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. > Hi, this is an open item for release 14 . The discussion seems to have gone silent for a couple of weeks. Are we in a position to make any decisions? I hear what Andres says, but is anyone acting on it? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Commits
-
Doc: Update notes about libc collation versions.
- b65431ca5e12 14.0 landed
-
Revert per-index collation version tracking feature.
- ec4831470826 14.0 landed
-
Rethink extraction of collation dependencies.
- f24b15699705 14.0 landed
-
Fix bogus collation-version-recording logic.
- ef387bed87f2 14.0 landed
-
Rename the "point is strictly above/below point" comparison operators.
- 0cc993278888 14.0 cited
-
Move catalog toast table declarations
- b4c9695e79f7 14.0 cited