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  (Peter Geoghegan <pg@heroku.com>)
Re: Collations and Replication; Next Steps  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Sequence Access Method WIP
Следующее
От: Álvaro Hernández Tortosa
Дата:
Сообщение: Re: PL/pgSQL 2