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
<[EMAIL PROTECTED]>


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to