Simon Riggs wrote:
As a result, I have thought that there may be a way to remove those pages from the xlog files immediately before being copied away to archive, without effecting crash recovery logic AT ALL. The archiver process could read the xlog files and re-write them exactly as read to another file, but without the full page images - writing exactly the current xlog record format. This would mean that the archived xlog files would then become variable length. Apart from that, not much other code need change. The recovery logic wouldn't need to change at all - the xlog files would just simply never have full page images to re-apply. The archive logic would need enhancing to do the read/re-write, but much of that same code needs to be written/adapted anyway for the offline xlog file reader. The archive code itself would simply copy to an intermediate file, say ARCHIVEFILE, just like we do on recovery - so the use of %p would still work as before and require redirecting only, no other changes.
So this means that the way to have an "hot spare" postgres that play the logs while are arriving is not applicable anymore ?
See Tom advice: http://archives.postgresql.org/pgsql-hackers/2004-08/msg00704.php and my success: http://archives.postgresql.org/pgsql-hackers/2004-08/msg00852.php
Am I right ?
Regards Gaetano Mendola
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
