Re: Collations and Replication; Next Steps
От | Peter Eisentraut |
---|---|
Тема | Re: Collations and Replication; Next Steps |
Дата | |
Msg-id | 5418A68A.9080407@gmx.net обсуждение исходный текст |
Ответ на | Collations and Replication; Next Steps (Matthew Kelly <mkelly@tripadvisor.com>) |
Ответы |
Re: Collations and Replication; Next Steps
Re: Collations and Replication; Next Steps |
Список | 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.
В списке pgsql-hackers по дате отправления: