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

Re: postgresql.conf archive_command example

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: 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-08 13:09:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Sep 8, 2011 at 2:05 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> That's an option. But I don't think that finding an existing file is so serious
> problem. The most common cases which cause a partially-filled archived
> file are;
> 1. The server crashes while WAL file is being archived, and then the server
>    restarts. In this case, the restarted server would find partially-filled
>    archived file.
> 2. In replication environment, the master crashes while WAL file is being
>    archived, and then a failover happens. In this case, new master would
>    find partially-filled archived file.
> In these cases, I don't think it's so unsafe to overwrite an existing file.

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.


No excuses.

Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,                                   work like a slave.

In response to


pgsql-hackers by date

Next:From: Ants AasmaDate: 2011-09-08 13:26:01
Subject: concurrent snapshots
Previous:From: Robert HaasDate: 2011-09-08 13:03:14
Subject: Re: pg_last_xact_insert_timestamp

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