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
> 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
> 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.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: