Re: postgresql.conf archive_command example

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: postgresql.conf archive_command example
Date: 2011-09-10 08:29:26
Message-ID: 201109101029.27316.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marti Raudsepp 2011-09-10 11:46:59 9.1rc1 bug: extension types not dropped with DROP SCHEMA CASCADE
Previous Message Fujii Masao 2011-09-10 06:15:15 Re: new createuser option for replication role