Re: Decreasing WAL size effects

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: pgsql <pgsql-general(at)postgresql(dot)org>
Subject: Re: Decreasing WAL size effects
Date: 2008-10-31 08:00:08
Message-ID: 490ABB08.9050708@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Christian Schröder 2008-10-31 08:01:29 Storage location of temporary files
Previous Message Jodok Batlogg 2008-10-31 07:49:07 tsearch2 problem

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-10-31 08:12:29 Re: WIP patch: convert SQL-language functions to return tuplestores
Previous Message Heikki Linnakangas 2008-10-31 07:40:04 Re: PG_PAGE_LAYOUT_VERSION 5 - time for change