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

Re: pitr replica dies on startup

From: Decibel! <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Frost <jeff(at)frostconsultingllc(dot)com>, pgsql-admin(at)postgresql(dot)org,Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: pitr replica dies on startup
Date: 2007-09-02 00:12:33
Message-ID: 20070902001233.GD38801@decibel.org (view raw or flat)
Thread:
Lists: pgsql-admin
On Fri, Aug 31, 2007 at 09:56:50PM -0400, Tom Lane wrote:
> Jeff Frost <jeff(at)frostconsultingllc(dot)com> writes:
> > That all seems reasonable enough.  Is it in the docs somewhere?  I
> > didn't find anything like this mentioned.  If not, could we get it
> > added as a note?
> 
> Yeah, it hadn't occurred to anyone to specify this, because we just
> thought of recovery_command as fetching from a static archive.
> We clearly need to document the expected semantics better.
> 
> I'm wondering whether we should discourage people from putting
> side-effects into the recovery_command, period.  You already found out
> that recovery can ask for the same file more than once, but what if it
> never asks for a particular file at all?  I'm not sure that can happen,
> just playing devil's advocate.

I'd rather go the route of documenting the details of how
(archive|recovery)_command is used; one of the huge benefits of our
system over others is the flexibility you have in being able to run
whatever command you want.

I know Simon was working on some improvements to the PITR docs, but I
don't know if that's been committed or not yet.
-- 
Decibel!, aka Jim Nasby                        decibel(at)decibel(dot)org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

In response to

pgsql-admin by date

Next:From: Kevin GrittnerDate: 2007-09-02 17:45:14
Subject: Managing pid file conflicts for multiple PostgreSQL instances
Previous:From: Decibel!Date: 2007-09-02 00:04:28
Subject: Re: rename a constraint?

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