>>But, if you do PITR using the same directory (which I haven't), I
>>think you would need to somehow replace the stats with the ones you
>>want, may be from your backup of the same (that is, of
>>pg_stat/*.stat), though I am not sure if that would be correct. I
>>doubt if WAL replay (as in a consistent recovery mechanism :-) )
>>accounts for the stats. I guess stats are not WAL logged (like changes
>>to table data) since they are managed using temporary files in
>>pg_stat_temp and hence may not be recoverable using WAL replay to a
>>particular state using PITR. but I may be wrong.
>>think you would need to somehow replace the stats with the ones you
>>want, may be from your backup of the same (that is, of
>>pg_stat/*.stat), though I am not sure if that would be correct. I
>>doubt if WAL replay (as in a consistent recovery mechanism :-) )
>>accounts for the stats. I guess stats are not WAL logged (like changes
>>to table data) since they are managed using temporary files in
>>pg_stat_temp and hence may not be recoverable using WAL replay to a
>>particular state using PITR. but I may be wrong.
>>Thoughts?
> I agree. Will try PITR with stats file from different timeline and confirm thisI did the following
1. Enabled archiving
2. Executed SQL's 3. Shutdown 4. copied data directory (including the pgstats.stat under global) and archive directory under backup/1
repeated 2,3,4 once more
So now i have 2 backup directories.
Now i created recovery.conf under backup/1/data. It has recovery command copying from backup1 archive.
Next i renamed pagstat.stat under backup1/data/global as pgstat_1.stat. Next i copied pgstat.stat from backup 2 into backup 1 (under the usual global directory).
Pointed the server to backup1 data directory and started it. Surprisingly it works with no complaints about wrong pgstat.stats
Thoughts?
regards
Sameer
