agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Christoph Berg <myon@debian.org>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Collation versioning
Date: Wed, 5 Sep 2018 21:10:14 +0200
Message-ID: <20180905191014.GA29241@msg.df7cb.de> (raw)
In-Reply-To: <CAEepm=0hoACQLFn8ro7jCO9-wTth2mXXS3K=s09gxKqN2jy8pA@mail.gmail.com> <CAEepm=3a5BC7CwsXZo3V4fw6YuAMT2nJ1krwtqOatb=vDqRWEA@mail.gmail.com>
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
view thread (188+ messages) latest in thread
Message-ID: <20180905191014.GA29241@msg.df7cb.de>
Permalink: ../20180905191014.GA29241@msg.df7cb.de/
Also on: postgresql.org/message-id/20180905191014.GA29241@msg.df7cb.de
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: myon@debian.org, thomas.munro@enterprisedb.com
Subject: Re: Collation versioning
In-Reply-To: <20180905191014.GA29241@msg.df7cb.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox