Brian Wipf wrote:
We are running a production server off of a new database that was
synchronized using PITR recovery. We found that many of the btree
indexes were out of sync with the underlying data after bringing the new
server out of recovery mode, but the data itself appeared to be okay.
Both servers have identical Intel processors and both are running 64-bit
PostgreSQL 8.2.4. The original server is running 64-bit openSUSE 10.2
(Linux 2.6.18.2-34-default #1 SMP Mon Jul 16 01:16:32 GMT 2007 x86_64
x86_64 x86_64 GNU/Linux) and the new server is running Mac OS X Leopard
Server.
This isn't necessarily safe. If your setup isn't *identical* then you
need to do a lot of checking to make sure this will work. In particular
you'd want to make sure that all your ./configure options are compatible
(e.g. --enable-integer-datetimes can change on-disk representations).
You also need to make sure there aren't any differences in behaviour in
any OS libraries used. That's not implausible since you're contrasting
Linux with a BSD-based system.
In the Continuous Archiving Point-In-Time Recovery section of the docs,
one of the caveats listed is:
"Operations on hash indexes are not presently WAL-logged, so replay will
not update these indexes. The recommended workaround is to manually
REINDEX each such index after completing a recovery operation"
Is it possible there are issues with btree indexes being maintained
properly as well? Any other ideas?
If there is a problem then it's a bug. However, it's quite likely that
you're seeing underlying platform differences. Sounds like you want
replication rather than PITR.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
