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.
> 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! -
> It'd be very cool if we shipped a tool that did that correctly (pg_walcopy
> maybe?) on all supported platforms.
In response to
pgsql-hackers by date
|Next:||From: Marti Raudsepp||Date: 2011-09-10 11:46:59|
|Subject: 9.1rc1 bug: extension types not dropped with DROP SCHEMA CASCADE|
|Previous:||From: Fujii Masao||Date: 2011-09-10 06:15:15|
|Subject: Re: new createuser option for replication role|