Re: postgresql.conf archive_command example

On Tue, Sep 6, 2011 at 10:11 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Sat, Sep 3, 2011 at 5:10 AM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> (2)  It should copy, not move, with protection against overwriting
>> an existing file.
>
> I agree that basically archive_command should not overwrite an existing file.
> But if the size of existing file is less than 16MB, it should do that.
> Otherwise,
> that WAL file would be lost forever.
>

I think best practice in this case is that if you ever find an
existing file with the same name already in place, you should error
and investigate. We don't ship around partially completed WAL files,
and finding an existing one probably means something went wrong. (Of
course, we use rsync instead of copy/move, so we have some better
guarantees about this).

> I have another feature request;
> (5) Maybe not in the initial version, but eventually it might be
> nice to support calling posix_fadvise(POSIX_FADV_DONTNEED)
> after copying a WAL file.
>

Can you go into more details on how you envision this working. I'm
mostly curious because I think rsync might already support this, which
would make it easy to incorporate.

On a side note, seeing this thread hasn't died, I'd encourage everyone
to take another look at OmniPITR,
https://github.com/omniti-labs/omnipitr. It's postgresql licensed,
solves a lot of the problems listed here, and I think makes for a good
example for people who want to accomplish more advanced awl management
goals. So far the biggest criticism we've gotten is that it wasn't
written in python, for some of you that might be a plus though ;-)

Robert Treat
play: xzilla.net
work: omniti.com