Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fxV9q-0001kO-2N for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Sep 2018 10:35:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fxV9m-0005rz-AP for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Sep 2018 10:35:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fxV9m-0005re-30 for pgsql-hackers@lists.postgresql.org; Wed, 05 Sep 2018 10:35:30 +0000 Received: from feynman.df7cb.de ([195.49.152.168]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fxV9j-0000nH-KM for pgsql-hackers@postgresql.org; Wed, 05 Sep 2018 10:35:29 +0000 Received: from msg.df7cb.de (unknown [IPv6:2003:5b:203b:100:7627:eaff:fe52:8e03]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by feynman.df7cb.de (Postfix) with ESMTPSA id 4250TT4qp1z3Dwk; Wed, 5 Sep 2018 12:35:25 +0200 (CEST) Date: Wed, 5 Sep 2018 12:35:25 +0200 From: Christoph Berg To: Thomas Munro Cc: Pg Hackers Subject: Re: Collation versioning Message-ID: <20180905103524.GA13620@msg.df7cb.de> Mail-Followup-To: Christoph Berg , Thomas Munro , Pg Hackers References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Re: Thomas Munro 2018-09-04 > I was reminded about that by recent news > about an upcoming glibc/CLDR resync that is likely to affect > PostgreSQL users (though, I guess, probably only when they do a major > OS upgrade). Or replicating/restoring a database to a newer host. > ... or, on a Debian system using the locales package, like this: > > libc_collation_version_command = 'dpkg -s locales | grep Version: | > sed "s/Version: //"' Ugh. This sounds horribly easy to get wrong on the user side. I could of course put that preconfigured into the Debian packages, but that would leave everyone not using any of the standard distro packagings in the rain. > Does anyone know > of a way to extract a version string from glibc using existing > interfaces? I heard there was an undocumented way but I haven't been > able to find it -- probably because I was, erm, looking in the > documentation. That sounds more robust. Googling around: https://www.linuxquestions.org/questions/linux-software-2/how-to-check-glibc-version-263103/ #include #include int main (void) { puts (gnu_get_libc_version ()); return 0; } $ ./a.out 2.27 Hopefully that version info is fine-grained enough. Christoph