>>> On Thu, Sep 6, 2007 at 7:31 PM, in message
<46E055A7(dot)EE98(dot)0025(dot)0(at)wicourts(dot)gov>, "Kevin Grittner"
>>>> On Thu, Sep 6, 2007 at 7:03 PM, in message
> <1189123422(dot)9243(dot)29(dot)camel(at)dogma(dot)ljc(dot)laika(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>
>> I think ... there's still room for a simple tool that can zero out
>> the meaningless data in a partially-used WAL segment before compression.
>> It seems reasonable to me, so long as you keep archive_timeout at
>> something reasonably high.
>> If nothing else, people that already have a collection of archived WAL
>> segments would then be able to compact them.
> That would be a *very* useful tool for us, particularly if it could work
> against our existing collection of old WAL files.
Management here has decided that it would be such a useful tool for our
organization that, if nobody else is working on it yet, it is something I
should be working on this week. Obviously, I would much prefer to do it
in a way which would be useful to the rest of the PostgreSQL community,
so I'm looking for advice, direction, and suggestions before I get started.
I was planning on a stand-alone executable which could be run against a
list of files to update them in-place, or to handle as single file as a
stream. The former would be useful for dealing with the accumulation of
files we've already got, the latter would be used in our archive script,
just ahead of gzip in the pipe.
Any suggestions on an existing executable to use as a model for "best
practices" are welcome, as are suggestions for the safest and most robust
techniques for identifying the portion of the WAL file which should be set
Finally, I assume that I should put this on pgfoundry?
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2007-09-24 22:58:48|
|Subject: MSVC build scripts status|
|Previous:||From: Chuck McDevitt||Date: 2007-09-24 21:16:30|
|Subject: Re: Suggestion for MSVC build|