After bringing up a PG 8.2.5 database restored from a base backup
taken from a warm standby, the following warnings are logged:
...
[2007-10-26 19:21:22 MDT] LOG: archived transaction log file
"000000010000017C000000E2"
WARNING: relation "category_click_history" page 250226 is
uninitialized --- fixing
WARNING: relation "category_click_history" page 250227 is
uninitialized --- fixing
[2007-10-26 19:22:22 MDT] LOG: archived transaction log file
"000000010000017C000000E3"
...
WARNING: relation "category_product" page 30364 is uninitialized ---
fixing
Most warnings are for tables that are constantly being inserted into.
When I restore the database to the same server using a base backup
from the main server, I don't get this problem. I'm not sure if it's a
bug or a problem with my procedures. If it's a bug fixed in 8.3, I can
wait for that.
The process I use that leads to the warnings is simple:
I use pg_controldata to determine the current checkpoint WAL location
of the standby server. I ensure I have this WAL file and all newer
WALs. I backup all files under the standby's database cluster
directory, including all tablespaces, which are soft linked. I restore
the database cluster directory to its new location and create soft
links in pg_tblspc to point to the proper tablespace directories just
backed up. I create the pg_xlog directory containing an archive_status
directory.
I bring up the database and it goes into archive recovery mode (using
the recovery.conf from the original standby's backup). I let it replay
WALs until it's in sync with the production server. I then bring it
out of archive recovery mode by having my restore_comand script return
non-zero once and the database is up and running. With the database
sitting idle, other than autovac, the warnings noted above are logged.
Other than the warnings, the database seems okay.
I have resumed taking base backups from the main server and it's not
terribly important that this even works. If anyone could shed any
insight though, I would appreciate the feedback.
Brian Wipf
<brian@xxxxxxxxxxxxxx>
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
