Re: postgresql.conf archive_command example - Mailing list pgsql-hackers

From Andres Freund
Subject Re: postgresql.conf archive_command example
Date
Msg-id 201109101029.27316.andres@anarazel.de
Whole thread Raw
In response to Re: postgresql.conf archive_command example  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
On Friday, September 09, 2011 08:59:43 PM Florian Pflug wrote:
> On Sep8, 2011, at 15:09 , Aidan Van Dyk wrote:
> > Personally, I think both of these show examples of why PG should be
> > looking hard at either providing a simple robust local directory based
> > archive_command, or very seriously pointing users at properly written
> > tools like omniptr, or ptrtools, walmgr, etc...
> > 
> > Neither of those cases should ever happen.  If you're copying a file
> > into the archive, and making it appear non-atomically in your archive,
> > your doing something wrong.
> 
> +1000.
> 
> Archiving WAL should be done by copying to a temp file and moving it
> into place. Before returning success, one should probably also do the
> fsync incantations the linux kernel guys argued are necessary to prevent
> the file from appearing empty if the machine crashes shortly after the
> move. (Yeah, they fixed that after enough people complained, but the fact
> that they even went as far as arguing their behaviour is correct according
> to POSIX makes me uneasy...)
The only problem being that its only fixed with certain mount options on a 
certain filesystem (ext3, ext4, data=ordered).
Every other filesystem (like e.g. XFS) still does it that way. And did it for 
at least a decade.
It makes me just as uneasy that so few people knew about that - preexisting! - 
problem...

> It'd be very cool if we shipped a tool that did that correctly (pg_walcopy
> maybe?) on all supported platforms.
+1


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: new createuser option for replication role
Next
From: Marti Raudsepp
Date:
Subject: 9.1rc1 bug: extension types not dropped with DROP SCHEMA CASCADE