On 9/21/11 10:07 AM, Robert Haas wrote:
> On Wed, Sep 21, 2011 at 1:03 PM, Josh Berkus wrote:
>>> Yeah, I get it. But I think standby would confuse them, too, just in
>>> a different set of situations.
>>
>> Other than PITR, what situations?
>
> Hot backup?
Hot backup == PITR. You're just not
On Wed, Sep 21, 2011 at 1:03 PM, Josh Berkus wrote:
>> Yeah, I get it. But I think standby would confuse them, too, just in
>> a different set of situations.
>
> Other than PITR, what situations?
Hot backup?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Com
> Yeah, I get it. But I think standby would confuse them, too, just in
> a different set of situations.
Other than PITR, what situations?
PITR is used by a minority of our users. Binary replication, if not
already used by a majority, will be in the future (it's certainly the
majority of my pro
On Wed, Sep 21, 2011 at 12:55 PM, Josh Berkus wrote:
>> Josh is arguing that we ought to use the term "replication", but it
>
> Actually, no. I'm arguing that we should use the term "standby", since
> that term is consistent with how we refer to replica servers throughout
> the docs, and the term
Robert,
> Josh is arguing that we ought to use the term "replication", but it
Actually, no. I'm arguing that we should use the term "standby", since
that term is consistent with how we refer to replica servers throughout
the docs, and the term "recovery" is not.
> seems to me that's just as misl
On Tue, Sep 20, 2011 at 3:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane wrote:
>>> Are we all talking about the same thing? In my mind recovery.conf is
>>> for configuring a point-in-time archive recovery run. It's got nothing
>>> to do with either r
> The point I'm trying to make is that it seems like this discussion is
> getting driven entirely by the standby case, without remembering that
> recovery.conf was originally designed for, and is still used in,
> a significantly different use-case. Maybe we had better take two
> steps back and th
Robert Haas writes:
> On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane wrote:
>> Are we all talking about the same thing? In my mind recovery.conf is
>> for configuring a point-in-time archive recovery run. It's got nothing
>> to do with either replication or standbys.
> Huh? How else can you create
On Tue, Sep 20, 2011 at 1:30 PM, Tom Lane wrote:
> Josh Berkus writes:
>> First, if we're going to change behavior, I assert that we should stop
>> calling stuff "recovery" and either call it "replica" or "standby". Our
>> use of the word "recovery" confuses users; it is historical in nature
>>
Josh Berkus writes:
> First, if we're going to change behavior, I assert that we should stop
> calling stuff "recovery" and either call it "replica" or "standby". Our
> use of the word "recovery" confuses users; it is historical in nature
> and requires an understanding of PostgreSQL internals to
On 9/20/11 10:09 AM, Robert Haas wrote:
> I like the idea of some kind of sentinel file that tells the server to
> start up in recovery mode. But instead of having the user remove it
> to cause a promotion, I think the server should remove it when it does
> promote. That's more like what we've do
On Tue, Sep 20, 2011 at 1:01 PM, Josh Berkus wrote:
> I'll go further and say that we only want one trigger file by default,
> one which either enables or disables recovery. I'll further suggest
> that we:
>
> a) have a standby.on file which puts the server in replica/recovery mode
> if it's dete
All,
First, if we're going to change behavior, I assert that we should stop
calling stuff "recovery" and either call it "replica" or "standby". Our
use of the word "recovery" confuses users; it is historical in nature
and requires an understanding of PostgreSQL internals to know why it's
called t
> I don't buy this argument at all. I don't believe that recovery.conf is
> part of anyone's automated processes at all, let alone to an extent that
> they won't be able to cope with a change to rationalize the file layout.
> And most especially I don't buy that someone who does want to keep usin
Simon Riggs writes:
> I sympathise with this view, to an extent.
> If people want to put all parameters in one file, they can do so. So +1 to
> that.
> Should they be forced to adopt that new capability by us deliberately
> breaking their existing setups? No. So -1 to that.
> If we do an autom
On Fri, Sep 16, 2011 at 1:13 PM, Peter Eisentraut wrote:
> On fre, 2011-09-16 at 01:32 -0400, Tom Lane wrote:
>> As far as the other issues go, I think there is actually a
>> prerequisite
>> discussion to be had here, which is whether we are turning the
>> recovery
>> parameters into plain old GUC
On Fri, Sep 16, 2011 at 3:54 AM, Fujii Masao wrote:
> On Thu, Sep 15, 2011 at 11:37 PM, Tom Lane wrote:
>> This seems like it's already predetermining the outcome of the argument
>> about recovery.conf. Mind you, I'm not unhappy with this choice, but
>> it's hardly implementing only behavior tha
On Fri, Sep 16, 2011 at 2:46 PM, Euler Taveira de Oliveira
wrote:
> On 15-09-2011 23:54, Fujii Masao wrote:
>>
>> #1
>> Use empty recovery.ready file to enter arhicve recovery. recovery.conf
>> is not read automatically. All recovery parameters are expected to be
>> specified in postgresql.conf. I
On Fri, Sep 16, 2011 at 9:25 PM, Peter Eisentraut wrote:
> On fre, 2011-09-16 at 11:54 +0900, Fujii Masao wrote:
>> #1
>> Use empty recovery.ready file to enter arhicve recovery. recovery.conf
>> is not read automatically. All recovery parameters are expected to be
>> specified in postgresql.conf.
On Sat, Sep 17, 2011 at 4:22 AM, Joshua Berkus wrote:
>> that makes it look like one of the WAL archive transfer trigger
>> files,
>> which does not seem like a great analogy. The pg_standby
>> documentation
>> suggests names like "foo.trigger" for failover triggers, which is a
>> bit
>> better a
On Fri, Sep 16, 2011 at 3:22 PM, Joshua Berkus wrote:
> No. pg_settings already has a couple dozen "developer" parameters which
> nobody not on this mailing list understands. Adding the recovery parameters
> to it wouldn't confuse anyone further, and would have the advantage of making
> the r
> I'm in favor of defining a separate, content-free trigger file to
> enable
> archive recovery. Not sure about the name "recovery.ready", though
> ---
> that makes it look like one of the WAL archive transfer trigger
> files,
> which does not seem like a great analogy. The pg_standby
> document
On 15-09-2011 23:54, Fujii Masao wrote:
#1
Use empty recovery.ready file to enter arhicve recovery. recovery.conf
is not read automatically. All recovery parameters are expected to be
specified in postgresql.conf. If you must specify them in recovery.conf,
you need to add "include 'recovery.conf'
On fre, 2011-09-16 at 11:54 +0900, Fujii Masao wrote:
> #1
> Use empty recovery.ready file to enter arhicve recovery. recovery.conf
> is not read automatically. All recovery parameters are expected to be
> specified in postgresql.conf. If you must specify them in recovery.conf,
> you need to add "i
On fre, 2011-09-16 at 01:32 -0400, Tom Lane wrote:
> As far as the other issues go, I think there is actually a
> prerequisite
> discussion to be had here, which is whether we are turning the
> recovery
> parameters into plain old GUCs or not. If they are plain old GUCs,
> then
> they will presuma
Fujii Masao writes:
> We have three choices. Which do you like the best?
I'm in favor of defining a separate, content-free trigger file to enable
archive recovery. Not sure about the name "recovery.ready", though ---
that makes it look like one of the WAL archive transfer trigger files,
which do
On Thu, Sep 15, 2011 at 11:37 PM, Tom Lane wrote:
> This seems like it's already predetermining the outcome of the argument
> about recovery.conf. Mind you, I'm not unhappy with this choice, but
> it's hardly implementing only behavior that's not being debated.
>
> If we're satisfied with not tre
Fujii Masao writes:
> It seems to need a bit more time until we've reached a consensus about
> the treatment of recovery.conf. How about committing the core patch
> first, and addressing the recovery.conf issue as a different patch later?
> The attached patch provides a core part of the feature,
On Thu, Sep 15, 2011 at 5:58 AM, Peter Eisentraut wrote:
> Alternatively, we could just forget about the whole thing and move
> everything to postgresql.conf and treat recovery.conf as a simple empty
> signal file. I don't know if that's necessarily better.
Seems like it might be simpler.
--
R
On tor, 2011-09-15 at 16:54 +0900, Fujii Masao wrote:
> On Wed, Sep 14, 2011 at 6:33 PM, Peter Eisentraut wrote:
> > On tis, 2011-09-13 at 17:10 +0100, Simon Riggs wrote:
> >> So treat postgresql.conf as if it has an automatic "include
> >> recovery.conf" in it. The file format is the same.
> >
>
Fujii Masao writes:
> If we'd like to treat recovery.conf as if it's under the data directory, I'm
> afraid that we should add complicated code to parse recovery.conf after
> the value of data_directory has been determined from postgresql.conf.
> Furthermore, what if recovery.conf has another sett
On Wed, Sep 14, 2011 at 6:33 PM, Peter Eisentraut wrote:
> On tis, 2011-09-13 at 17:10 +0100, Simon Riggs wrote:
>> So treat postgresql.conf as if it has an automatic "include
>> recovery.conf" in it. The file format is the same.
>
> Sounds good. That would also have the merit that you could use,
On tis, 2011-09-13 at 17:10 +0100, Simon Riggs wrote:
> So treat postgresql.conf as if it has an automatic "include
> recovery.conf" in it. The file format is the same.
Sounds good. That would also have the merit that you could use, say,
different memory settings during recovery.
--
Sent via
On Wed, Sep 14, 2011 at 1:10 AM, Simon Riggs wrote:
> On Tue, Sep 13, 2011 at 2:51 PM, Peter Eisentraut wrote:
>> On tis, 2011-09-13 at 14:46 +0900, Fujii Masao wrote:
>>> Are you still thinking the backward-compatibility (i.e., the
>>> capability to specify recovery parameters in recovery.conf)
On Tue, Sep 13, 2011 at 2:51 PM, Peter Eisentraut wrote:
> On tis, 2011-09-13 at 14:46 +0900, Fujii Masao wrote:
>> Are you still thinking the backward-compatibility (i.e., the
>> capability to specify recovery parameters in recovery.conf) is
>> required?
>
> I think parameters related to a partic
On tis, 2011-09-13 at 14:46 +0900, Fujii Masao wrote:
> Are you still thinking the backward-compatibility (i.e., the
> capability to specify recovery parameters in recovery.conf) is
> required?
I think parameters related to a particular recovery, e.g.,
recovery_target_time, fit better into a reco
On Sat, Sep 10, 2011 at 12:18 AM, Simon Riggs wrote:
> On Fri, Sep 9, 2011 at 3:05 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> I have to wonder though, if it wouldn't be less confusing to just get
>>> rid of recovery.conf and use a *different* file for this. Just to make
>>> it clear it's
On Fri, Sep 9, 2011 at 8:27 PM, Magnus Hagander wrote:
If the same parameter is specified in both file, the setting in
recovery.conf
overrides that in postgresql.conf. In this case, SHOW command displays
the settings in postgresql.conf even though they are not used at all. Eve
On Sat, Sep 10, 2011 at 01:07, Greg Stark wrote:
> On Fri, Sep 9, 2011 at 6:40 PM, Josh Berkus wrote:
>> I'm in favor of this. People are sufficiently confused by the existing
>> behavior that we're not going to confuse them further by changing it.
>>
>
> Fwiw as someone who *was* confused previ
On Fri, Sep 9, 2011 at 6:40 PM, Josh Berkus wrote:
> I'm in favor of this. People are sufficiently confused by the existing
> behavior that we're not going to confuse them further by changing it.
>
Fwiw as someone who *was* confused previously, it now makes perfect
sense to me. "We have postgres
On 9/9/11 7:05 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> I have to wonder though, if it wouldn't be less confusing to just get
>> rid of recovery.conf and use a *different* file for this. Just to make
>> it clear it's not a config file, but just a boolean exists/notexists
>> state.
>
> +1.
On Fri, Sep 9, 2011 at 3:05 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> I have to wonder though, if it wouldn't be less confusing to just get
>> rid of recovery.conf and use a *different* file for this. Just to make
>> it clear it's not a config file, but just a boolean exists/notexists
>> s
Magnus Hagander writes:
> I have to wonder though, if it wouldn't be less confusing to just get
> rid of recovery.conf and use a *different* file for this. Just to make
> it clear it's not a config file, but just a boolean exists/notexists
> state.
+1. If it's not a configuration file anymore, i
On Fri, Sep 9, 2011 at 13:15, Fujii Masao wrote:
> On Fri, Sep 9, 2011 at 7:21 PM, Magnus Hagander wrote:
>> On Fri, Sep 9, 2011 at 11:56, Fujii Masao wrote:
>>> Hi,
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php
>>>
>>> In previous discussion, we've reached the consen
On Fri, Sep 9, 2011 at 7:21 PM, Magnus Hagander wrote:
> On Fri, Sep 9, 2011 at 11:56, Fujii Masao wrote:
>> Hi,
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php
>>
>> In previous discussion, we've reached the consensus that we should unite
>> recovery.conf and postgresql.c
On Fri, Sep 9, 2011 at 11:56, Fujii Masao wrote:
> Hi,
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg02343.php
>
> In previous discussion, we've reached the consensus that we should unite
> recovery.conf and postgresql.conf. The attached patch does that. The
> patch is WIP, I'll have
101 - 146 of 146 matches
Mail list logo
