Re: Hot standby and synchronous replication status - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Hot standby and synchronous replication status
Date
Msg-id 9774FC1A-4306-49E4-A4DE-93F6BCFEC1F7@hi-media.com
Whole thread Raw
In response to Re: Hot standby and synchronous replication status  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Hot standby and synchronous replication status  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Le 11 août 09 à 23:30, Robert Haas a écrit :

> On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine<dfontaine@hi-media.com
> > wrote:
>> We should somehow provide a default archive and restore command
>> integrated
>> into the main product, so that it's as easy as turning it 'on' in the
>> configuration for users to have something trustworthy: PostgreSQL
>> will keep
>> past logs into a pg_xlog/archives subdir or some other default
>> place, and
>> will know about the setup at startup time when/if needed.
>
> I might be missing something, but isn't this completely silly?  If you
> archive your logs to the same partition where you keep your database
> cluster, it seems to me that you might as well delete them.  Even
> better, turn off XLogArchiving altogether and save yourself the
> overhead of not using WAL-bypass.

Nice, the pushback is about the default location, thanks for
supporting the idea :)

Seriously, debian package will install pg_xlog in $PGDATA which is
often not what I want. So first thing after install, I stop the
cluster, move the pg_xlog, setup a ln -s and restart. I figured having
to do the same for setting up archiving would make my day, when
compared to current documentation setup. Any better idea for a safe
enough default location is welcome, of course.

Oh, and I hope you didn't read that the archive mode be 'on' by
default in my proposal, because that's not what I meant.

Regards,
--
dim

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: machine-readable explain output v4
Next
From: Peter Eisentraut
Date:
Subject: Re: Re: pgsql: Ship documentation without intermediate tarballs Documentation