Re: Collation versioning
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Douglas Doole <dougdoole@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>,
Christoph Berg <myon@debian.org>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-11-04T03:58:08Z
Lists: pgsql-hackers
Attachments
- 0001-Remove-pg_collation.collversion-v2.patch (application/octet-stream) patch v2-0001
- 0002-Add-pg_depend.refobjversion-v2.patch (application/octet-stream) patch v2-0002
- 0003-Track-collation-versions-for-indexes-v2.patch (application/octet-stream) patch v2-0003
On Fri, Nov 1, 2019 at 2:21 AM Julien Rouhaud <rjuju123@gmail.com> wrote: > Are you planning to continue working on it? For the record, that's > something needed to be able to implement a filter in REINDEX command > [1]. Bonjour Julien, Unfortunately I haven't had time to work on it seriously, but here's a quick rebase to get the proof-of-concept back into working shape. It's nice to see progress in other bits of the problem-space. I hope to have time to look at this patch set again soon, but if you or someone else would like hack on or think about it too, please feel free! Yes indeed this is exactly the same problem that you're trying to solve, approached from a different starting point. Here are some problems to think about: * We'd need to track dependencies on the default collation once we have versioning for that (see https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com). That is how most people actually consume collations out there in real life, and yet we don't normally track dependencies on the default collation and I don't know if that's simply a matter of ripping out all the code that looks like "xxx != DEFAULT_COLLATION_ID" in the dependency analysis code or if there's more to it. * Andres mentioned off-list that pg_depend rows might get blown away and recreated in some DDL circumstances. We need to look into that. * Another is that pg_upgrade won't preserve pg_depend rows, so you'd need some catalog manipulation (direct or via new DDL) to fix that. * Some have expressed doubt that pg_depend is the right place for this; let's see if any counter-proposals appear. > # reindex table t1; > WARNING: 01000: index "t1_val_idx" depends on collation 13330 version > "a153.97.35.8", but the current version is "153.97.35.8" > DETAIL: The index may be corrupted due to changes in sort order. > HINT: REINDEX to avoid the risk of corruption. > LOCATION: index_check_collation_version, index.c:1263 Duh. Yeah, that's stupid and needs to be fixed somehow.
Commits
-
Doc: Document known problem with Windows collation versions.
- 1bf946bd43e5 14.0 landed
-
Add collation versions for FreeBSD.
- ca051d8b101d 14.0 landed
-
Tolerate version lookup failure for old style Windows locale names.
- 9f12a3b95dd5 14.0 landed
-
Track collation versions for indexes.
- 257836a75585 14.0 landed
-
Add pg_depend.refobjversion.
- cd6f479e79f3 14.0 landed
-
Remove pg_collation.collversion.
- 7d1297df0830 14.0 landed
-
Fix the MSVC build for versions 2015 and later.
- a169155453e3 13.0 cited
-
Add collation versions for Windows.
- 352f6f2df60f 13.0 cited
-
Implement type regcollation
- a2b1faa0f279 13.0 landed
-
Use libc version as a collation version on glibc systems.
- d5ac14f9ccdd 13.0 landed
- 9f90b1d08d79 13.0 landed
-
Make type "name" collation-aware.
- 586b98fdf1aa 12.0 cited