From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Collation versioning |
Date: | 2018-09-05 19:10:14 |
Message-ID: | 20180905191014.GA29241@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: Thomas Munro 2018-09-05 <CAEepm=3a5BC7CwsXZo3V4fw6YuAMT2nJ1krwtqOatb=vDqRWEA(at)mail(dot)gmail(dot)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(at)mail(dot)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2018-09-05 19:15:58 | Re: Bug fix for glibc broke freebsd build in REL_11_STABLE |
Previous Message | Tom Lane | 2018-09-05 19:05:42 | Re: Bug fix for glibc broke freebsd build in REL_11_STABLE |