If Pg truncated the WAL files before calling archive_command, and would accept truncated WAL files on restore, that'd be really useful.
On second thought - that'd prevent reuse of WAL files, or at least force the filesystem to potentially allocate new storage for the part that was truncated.
Is it practical or sane to pass another argument to the archive_command: a byte offset within the WAL file that is the last byte that must be copied? That way, the archive_command could just avoid reading any garbage in the first place, and write a truncated WAL file to the archive, but Pg wouldn't have to do anything to the original files. There'd be no need for a tool like pg_clearxlogtail, as the core server would just report what it already knows about the WAL file.
Sound practical / sane? -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
