Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-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

pgsql-hackers by date

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

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group