On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> 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?
The timezone case you highlight here seems quite distinct from what
Matthew is talking about, because in point of fact the on-disk
representation is merely *interpreted* with reference to the timezone
database. So, you could have an inconsistency between standbys
concerning what the time was in a particular timezone at a particular
timestamp value as reported by the timestamptz output function, but
both standbys would be correct on their own terms, which isn't too
bad. You still cannot have a situation where on a single standby, a
value isn't returned by an index scan that patently exists in the
table on the same standby (i.e. index corruption); the timezone isn't
actually stored (just an offset from a special Postgres epoch). As for
the PostGIS example, I think that they'd know better than to change
the behavior of an established opclass B-Tree support function 1. If
people that author opclasses don't read the documentation on how to do
so correctly, what chance do regular DBAs have? Should they make sure
that operator classes are authored correctly in each and every
instance? Surely not.
Even if I was wrong about all of this, we should treat text as a
special case, a case worth making every effort for.
--
Peter Geoghegan