Re: Collation versioning
От | Thomas Munro |
---|---|
Тема | Re: Collation versioning |
Дата | |
Msg-id | CAEepm=0hoACQLFn8ro7jCO9-wTth2mXXS3K=s09gxKqN2jy8pA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collation versioning (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: Collation versioning
|
Список | pgsql-hackers |
On Wed, Sep 5, 2018 at 8:20 AM Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Wed, Sep 5, 2018 at 3:35 AM Christoph Berg <myon@debian.org> wrote: > > int main (void) { puts (gnu_get_libc_version ()); return 0; } > > > > $ ./a.out > > 2.27 > > 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? 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. So, it's not ideal but perhaps worth considering on the grounds that it's better than nothing? -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: