Skip site navigation (1) Skip section navigation (2)

Re: postgresql.conf archive_command example

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: 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>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: postgresql.conf archive_command example
Date: 2011-09-09 18:59:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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...)

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

best regards,
Florian Pflug

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2011-09-09 19:11:41
Subject: Re: postgresql.conf archive_command example
Previous:From: Florian PflugDate: 2011-09-09 18:46:51
Subject: Re: fsyncing data to disk

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group