Re: Collation versioning
Christoph Berg <myon@debian.org>
From: Christoph Berg <myon@debian.org>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-09-05T19:10:14Z
Lists: pgsql-hackers
Re: Thomas Munro 2018-09-05 <CAEepm=3a5BC7CwsXZo3V4fw6YuAMT2nJ1krwtqOatb=vDqRWEA@mail.gmail.com> > > Hopefully that version info is fine-grained enough. > > Hmm. I was looking for locale data version, not libc.so itself. I > realise they come ultimately from the same source package, but are the > locale definitions and libc6 guaranteed to be updated at the same > time? I see that the locales package depends on libc-bin >> 2.27 (no > upper bound), which in turn depends on libc6 >> 2.27, << 2.28. So > perhaps you can have a system with locales 2.27 and libc6 2.28? No because libc6.deb "breaks" locales << 2.27: Package: libc6 Source: glibc Version: 2.27-5 Breaks: [...] locales (<< 2.27), locales-all (<< 2.27), (I can't tell off-hand why this isn't just a stricter dependency in locales.deb, but it's probably because this variant works better for upgrades.) > I also wonder if there are some configurations where they could get out > of sync because of manual use of locale-gen or something like that. > Clearly most systems would have them in sync through apt-get upgrade > though, so maybe gnu_get_libc_version() would work well in practice? I'd hope so. I'm more worried about breakage because of fixes applied within one glibc version (2.27-5 vs 2.27-6), but I guess Debian's glibc maintainers are clueful enough not to do that. Re: Thomas Munro 2018-09-05 <CAEepm=0hoACQLFn8ro7jCO9-wTth2mXXS3K=s09gxKqN2jy8pA@mail.gmail.com> > And even if they are, what if your cluster is still running and still > has the older libc.so.6 mapped in? Newly forked backends will see new > locale data but gnu_get_libc_version() will return the old string. > (Pointed out off-list by Andres.) Eventually you restart your cluster > and start seeing the error. That problem isn't protected against by PG itself. I've seen clusters that were upgraded on disk but not restarted yet where every plpgsql invocation was throwing symbol errors. So I guess we don't have to try harder for libc. > So, it's not ideal but perhaps worth considering on the grounds that > it's better than nothing? Ack. Christoph
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