On Wed, Sep 17, 2014 at 9:07 AM, Matthew Kelly <mke...@tripadvisor.com> wrote:
> Here is where I think the timezone and PostGIS cases are fundamentally 
> different:
> I can pretty easily make sure that all my servers run in the same timezone.  
> That's just good practice.  I'm also going to install the same version of 
> PostGIS everywhere in a cluster.  I'll build PostGIS and its dependencies 
> from the exact same source files, regardless of when I build the machine.
> Timezone is a user level setting; PostGIS is a user level library used by a 
> subset.
> glibc is a system level library, and text is a core data type, however.  
> Changing versions to something that doesn't match the kernel can lead to 
> system level instability, broken linkers, etc.  (I know because I tried).  
> Here are some subtle other problems that fall out:
>  * Upgrading glibc, the kernel, and linker through the package manager in 
> order to get security updates can cause the corruption.
>  * A basebackup that is taken in production and placed on a backup server 
> might not be valid on that server, or your desktop machine, or on the spare 
> you keep to do PITR when someone screws up.
>  * Unless you keep _all_ of your clusters on the same OS, machines from your 
> database spare pool probably won't be the right OS when you add them to the 
> cluster because a member failed.
> Keep in mind here, by OS I mean CentOS versions.  (we're running a mix of 
> late 5.x and 6.x, because of our numerous issues with the 6.x kernel)
> The problem with LC_IDENTIFICATION is that every machine I have seen reports 
> revision "1.0", date "2000-06-24".  It doesn't seem like the versioning is 
> being actively maintained.
> I'm with Martjin here, lets go ICU, if only because it moves sorting to a 
> user level library, instead of a system level.  Martjin do you have a link to 
> the out of tree patch?  If not I'll find it.  I'd like to apply it to a 
> branch and start playing with it.

What I find astonishing is that whoever maintains glibc (or the Red
Hat packaging for it) thinks it's OK to change the collation order in
a minor release.  I'd understand changing it between, say, RHEL 6 and
RHEL 7.  But the idea that minor release, supposedly safe updates
think they can whack this around without breaking applications really
kind of blows my mind.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to