Re: Collation versioning

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Douglas Doole <dougdoole(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation versioning
Date: 2020-02-15 08:29:52
Message-ID: 20200215082952.GA11655@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Feb 13, 2020 at 09:44:40AM +1300, Thomas Munro wrote:
> On Thu, Feb 13, 2020 at 9:16 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > On Wed, Feb 12, 2020 at 08:55:06PM +0100, Laurenz Albe wrote:
> > > I didn't study the patch in detail, but do I get it right that there will be no
> > > warnings about version incompatibilities with libc collations?
> >
> > No, libc is also be supported (including the default collation), as long as we
> > have a way to get the version. Unfortunately, that means only linux/glibc. I
> > think that there was some previous discussion to work around that limitation
> > for other systems, using some kind of hash of the underlying collation files,
> > as Peter mentioned recently, but that's not part of this patchset.
> Yeah, this is about the cataloguing infrastructure part, to get the
> model and mechanisms right. To actually get version information from
> the underlying collation provider, there will need to be a series of
> per-OS projects. For glibc right now, it's done, but we just use the
> whole glibc version as a proxy (sadly we know this can give false
> positives and false negatives, but is expected to work a lot better
> than nothing). I hope we can get a proper CLDR version out of that
> library one day. For FreeBSD libc, I have patches, I just need more
> round tuits. For Windows, there is
> which I'm planning to
> commit soonish, after some more thought about the double-version
> thing. Then there is the "run a user-supplied script that gives me a
> version" concept, which might work and perhaps allow package
> maintainers to supply a script that works on each system. Again,
> that'd be a separate project.

Thanks for working on that, it'll be great improvements!

> I guess there will probably always be
> some OSes that we can't get the data from so we'll probably always
> have to support "don't know" mode.

I realized this morning that I didn't add test to validate that we emit the
expected warnings in case of version mismatch. While adding some, I found that
for the unknown versino, my code was actually testing the "versioning support
for that lib on that system is now supported" and not "you apparently upgraded
from pre-v13 with supported collation library versioning, and the version was
marked as unknown". Attached v9 fixes the test to handle both cases.

I also added TAP regression tests for version mismatch checking in the
src/test/locale tests. This subdirectory wasn't included by default, probably
because there was no "check" or "installcheck" target so building test-ctype
was pointless, it's now included by default.

Attachment Content-Type Size
0001-Remove-pg_collation.collversion-v9.patch text/plain 23.4 KB
0002-Add-pg_depend.refobjversion-v9.patch text/plain 11.6 KB
0003-Implement-type-regcollation-v9.patch text/plain 8.9 KB
0004-Track-collation-versions-for-indexes-v9.patch text/plain 62.3 KB
0005-Preserve-index-dependencies-on-collation-during-pg_u-v9.patch text/plain 42.3 KB
0006-Add-a-new-ALTER-INDEX-name-ALTER-COLLATION-name-REFR-v9.patch text/plain 16.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message 曾文旌 (义从) 2020-02-15 09:56:42 Re: [Proposal] Global temporary tables
Previous Message Pavel Stehule 2020-02-15 08:05:01 Re: proposal: schema variables