Re: Collations and Replication; Next Steps

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Matthew Kelly <mkelly(at)tripadvisor(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Cc: Matthew Spilich <mspilich(at)tripadvisor(dot)com>
Subject: Re: Collations and Replication; Next Steps
Date: 2014-09-16 21:07:22
Message-ID: 5418A68A.9080407@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/16/14 12:06 PM, Matthew Kelly wrote:
> The second and far more challenging problem is how do we fix this issue?
> As of our last discussion, Peter Geoghegan revived the proposal of
> using ICU as an alternative.
> (http://www.postgresql.org/message-id/CAEYLb_WvdCzuL=Cyf1xyzjwn-1CVo6kZEaWMKbxTS3jPhtjOig@mail.gmail.com)
> I do not feel qualified to compare the value of this library to other
> options, but I am certainly willing to help with the patch process once
> a direction has been selected.

It seems to me that this is a more general problem that can affect any
data type that relies on anything external. For example, you could
probably create a case where indexes are corrupted if you have two
different time zone databases. Or what if you use PostGIS and one of
the libraries it uses has different rounding behaviors in different
versions?

Even in the absence of such external dependencies, there will still be
problems like this if you don't upgrade all nodes participating in
replication at the same time.

Clearly, this is worth documenting, but I don't think we can completely
prevent the problem. There has been talk of a built-in index integrity
checking tool. That would be quite useful.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-09-16 21:57:00 Re: Collations and Replication; Next Steps
Previous Message Petr Jelinek 2014-09-16 21:00:46 Re: Sequence Access Method WIP