> Right now, Warm Standby has same functionality as equivalent Oracle
feature - i.e. no way to confirm absence of corruption. However, WAL
records contain CRC checks that ensure the transferred data is correct,
which is more than most other replication techniques posess. Hot Standby
will allow access to data blocks to allow them to be read and checked,
though that is also possible with an external utility to some extent.
Do you have a link to documentation on how to do this?
It probably isn't practical with any replication system to confirm the
exact contents of both nodes while replication is running at reasonable
speed. Some heuristics may be possible.
agreed
Do you have anything in mind, other than "detect corruption"?
Really what I am after, is being able to say 'yes our replication is as
error-free as it can be' with the most amount of certainty as possible.
How can I prevent this
error from occurring ?
You haven't shown us the error, just what happens afterwards.
I might have written too fast. I am curious to know what causes the
message to appear in the logs. It only appears when a instance is
shutdown and then restarted again. Is there some thing I can do so that
the statement isn't triggered when I restart the warm-standby instance?
could it be a setting that I have missed?
For reference, here is the head of the 2 log files created when the
instance was restarted
$ ggrep -A 1 -B 1 HINT *
edb-2009-04-07_012241.log-2009-04-07 01:22:41.361 GMT,,,,1750,,,1, //
LOG: database system was interrupted while in recovery at log time
2009-04-02 17:04:54 GMT
edb-2009-04-07_012241.log:2009-04-07 01:22:41.361 GMT,,,,1750,,,2, //
HINT: If this has occurred more than once some data may be corrupted
and you may need to choose an earlier recovery target.
edb-2009-04-07_012241.log-2009-04-07 01:22:41.362 GMT,,,,1750,,,3, //
LOG: starting archive recovery
--
edb-2009-04-07_013609.log-2009-04-07 01:36:09.424 GMT,,,,1920,,,1, //
LOG: database system was interrupted while in recovery at log time
2009-04-02 17:04:54 GMT
edb-2009-04-07_013609.log:2009-04-07 01:36:09.424 GMT,,,,1920,,,2, //
HINT: If this has occurred more than once some data may be corrupted
and you may need to choose an earlier recovery target.
edb-2009-04-07_013609.log-2009-04-07 01:36:09.424 GMT,,,,1920,,,3, //
LOG: starting archive recovery
--
edb-2009-04-27_071121.log-2009-04-27 07:11:21.213 GMT,,,,8261,,,1, //
LOG: database system was interrupted while in recovery at log time
2009-04-27 06:55:08 GMT
edb-2009-04-27_071121.log:2009-04-27 07:11:21.213 GMT,,,,8261,,,2, //
HINT: If this has occurred more than once some data may be corrupted
and you may need to choose an earlier recovery target.
edb-2009-04-27_071121.log-2009-04-27 07:11:21.213 GMT,,,,8261,,,3, //
LOG: starting archive recovery
--
edb-2009-04-27_071747.log-2009-04-27 07:17:47.819 GMT,,,,8328,,,1, //
LOG: database system was interrupted while in recovery at log time
2009-04-27 06:55:08 GMT
edb-2009-04-27_071747.log:2009-04-27 07:17:47.819 GMT,,,,8328,,,2, //
HINT: If this has occurred more than once some data may be corrupted
and you may need to choose an earlier recovery target.
edb-2009-04-27_071747.log-2009-04-27 07:17:47.819 GMT,,,,8328,,,3, //
LOG: starting archive recovery
Thanks,
-Said
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
