Re: unite recovery.conf and postgresql.conf - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: unite recovery.conf and postgresql.conf
Date
Msg-id DA6BA0B7-C73E-4CED-A7B6-7769A9B3C223@phlo.org
Whole thread Raw
In response to Re: unite recovery.conf and postgresql.conf  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Sep23, 2011, at 17:46 , Peter Eisentraut wrote:
> On tis, 2011-09-20 at 16:38 -0400, Robert Haas wrote:
>> For now, I think we're best off not changing the terminology, and
>> confining the remit of this patch to (a) turning all of the existing
>> recovery.conf parameters into GUCs and (b) replacing recovery.conf
>> with a sentinel file a sentinel file (name TBB) to indicate that the
>> server is to start in recovery mode.  The naming isn't great but the
>> more we change at once the less chance of reaching agreement.  It
>> seems like we have pretty broad agreement on the basics here, so let's
>> start with that.
>
> The only thing that's slightly bogus about that is that if you were
> doing an archive recovery, you'd have to edit the main postgresql.conf
> with one-shot parameters for that particular recovery (and then delete
> them again, or leave them in place, confusing the next guy).  But
> perhaps that's worth the overall simplification.

OTOH, if they're GUCs, you can specify them on the postmaster's
command line. We could even get crazy and patch pg_ctl to allow
 <untar base backup> pg_ctl recover -D <dir> --target_xid=<the xid that broke stuff> --target_inclusive=false pg_ctl
start-D <dir> 

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.2] "database" object class of contrib/sepgsql
Next
From: Robert Haas
Date:
Subject: Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)