> 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
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?
In response to
pgsql-hackers by date
|Next:||From: Pavel Stehule||Date: 2008-10-31 08:12:29|
|Subject: Re: WIP patch: convert SQL-language functions to return tuplestores|
|Previous:||From: Heikki Linnakangas||Date: 2008-10-31 07:40:04|
|Subject: Re: PG_PAGE_LAYOUT_VERSION 5 - time for change|
pgsql-general by date
|Next:||From: Christian Schröder||Date: 2008-10-31 08:01:29|
|Subject: Storage location of temporary files|
|Previous:||From: Jodok Batlogg||Date: 2008-10-31 07:49:07|
|Subject: tsearch2 problem|