Well that is interesting :_)
Here is what I am doing on the removal front (I am keeping pg_xlog *now*):
$ cd $PGDATA $ pg_ctl stop $ ls|grep -v pg_xlog|xargs rm -rf
The contents of the archive directory just before recovery starts:
$ ls -l $PGDATA/../7.5-archive
total 49212
-rw------- 1 postgres postgres 16777216 Jul 22 14:59 000000010000000000000000
-rw------- 1 postgres postgres 16777216 Jul 22 14:59 000000010000000000000001
-rw------- 1 postgres postgres 16777216 Jul 22 14:59 000000010000000000000002
But here is recovery startup log:
LOG: database system was shut down at 2004-07-22 14:58:57 NZST
LOG: starting archive recovery
LOG: restore_command = "cp /data1/pgdata/7.5-archive/%f %p"
cp: cannot stat `/data1/pgdata/7.5-archive/00000001.history': No such file or directory
LOG: restored log file "000000010000000000000000" from archive
LOG: checkpoint record is at 0/A4D3E8
LOG: redo record is at 0/A4D3E8; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 496; next OID: 17229
LOG: archive recovery complete
LOG: database system is ready
regards
Mark
Tom Lane wrote:
Huh? It works fine.
The bit you may be missing is that if you blow away $PGDATA including pg_xlog/, you won't be able to recover past whatever you have in your WAL archive area. The archive is certainly not going to include the current partially-filled WAL segment, and it might be missing a few earlier segments if the archival process isn't speedy. So you need to keep those recent segments in pg_xlog/ if you want to recover to current time or near-current time.
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
