On 02.10.2010 00:20, Tom Lane wrote:
Josh Berkus writes:
Then instead of having a trigger file, the admin could just update the
status file in recovery.conf and save it (or overwrite the file).
This doesn't seem like a terribly bright idea. We've expended megabytes
of list traffic on arguing
On Fri, Oct 1, 2010 at 4:00 PM, Josh Berkus wrote:
>
> Our current arrangement of having a postgresql.conf file, a
> recovery.conf file, and potentially a trigger file (during final
> recovery) seems horribly hackish and impossible to manage neatly.
>
all the contrary, IMHO what we have now seems
Josh Berkus writes:
> Then instead of having a trigger file, the admin could just update the
> status file in recovery.conf and save it (or overwrite the file).
This doesn't seem like a terribly bright idea. We've expended megabytes
of list traffic on arguing about automatic updates of config fi
On 10/1/10 4:05 AM, Robert Haas wrote:
>>> And
>>> >> have PG poll that text file periodically so that you could update it and
>>> >> it would fail over?
>> >
>> > Hmm.. instead of that text file (i.e., recovery.conf), trigger file is
>> > periodically polled by the standby server.
>
> I'm not s
On 1 October 2010 15:41, Robert Haas wrote:
> On Fri, Oct 1, 2010 at 8:40 AM, Simon Riggs wrote:
>> On Fri, 2010-10-01 at 18:47 +0900, Fujii Masao wrote:
>>> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
>>> > On 9/29/10 7:54 PM, Tom Lane wrote:
>>> >> Robert Haas writes:
>>> >>> But that'
On Fri, Oct 1, 2010 at 8:40 AM, Simon Riggs wrote:
> On Fri, 2010-10-01 at 18:47 +0900, Fujii Masao wrote:
>> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
>> > On 9/29/10 7:54 PM, Tom Lane wrote:
>> >> Robert Haas writes:
>> >>> But that's not what Tom is talking about, I don't think: you
On Fri, 2010-10-01 at 18:47 +0900, Fujii Masao wrote:
> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
> > On 9/29/10 7:54 PM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> But that's not what Tom is talking about, I don't think: you might
> >>> also want a way to explicitly whack the flag i
On Oct 1, 2010, at 5:47 AM, Fujii Masao wrote:
> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
>> On 9/29/10 7:54 PM, Tom Lane wrote:
>>> Robert Haas writes:
But that's not what Tom is talking about, I don't think: you might
also want a way to explicitly whack the flag in pg_contr
On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
> On 9/29/10 7:54 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> But that's not what Tom is talking about, I don't think: you might
>>> also want a way to explicitly whack the flag in pg_control around.
>>> That would probably be along the lines
On 9/29/10 7:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> But that's not what Tom is talking about, I don't think: you might
>> also want a way to explicitly whack the flag in pg_control around.
>> That would probably be along the lines of pg_resetxlog. I'm not sure
>> how much use case there
Robert Haas writes:
> But that's not what Tom is talking about, I don't think: you might
> also want a way to explicitly whack the flag in pg_control around.
> That would probably be along the lines of pg_resetxlog. I'm not sure
> how much use case there is for such a thing, but if it's needed it
On Wed, Sep 29, 2010 at 3:09 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> On Wed, Sep 29, 2010 at 10:02 AM, Tom Lane wrote:
>>> I think keeping the status information in a transient text file may
>>> still be a good design choice. If you push it into pg_control it will
>>> be impossible
Robert Haas writes:
> On Wed, Sep 29, 2010 at 10:02 AM, Tom Lane wrote:
>> I think keeping the status information in a transient text file may
>> still be a good design choice. If you push it into pg_control it will
>> be impossible to modify by hand.
>
> It could be done with a trivial tool, th
On Wed, Sep 29, 2010 at 10:02 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas wrote:
>>> The idea of relying on the existence of recovery.conf to determine
>>> whether we should continue recovery forever or switch to normal
>>> running seems somewhat kl
Fujii Masao writes:
> On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas wrote:
>> The idea of relying on the existence of recovery.conf to determine
>> whether we should continue recovery forever or switch to normal
>> running seems somewhat klunky to me. It mixes up settings with
>> control informa
On Wed, Sep 29, 2010 at 3:14 AM, Fujii Masao wrote:
> On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas wrote:
>> The idea of relying on the existence of recovery.conf to determine
>> whether we should continue recovery forever or switch to normal
>> running seems somewhat klunky to me. It mixes up
On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas wrote:
> The idea of relying on the existence of recovery.conf to determine
> whether we should continue recovery forever or switch to normal
> running seems somewhat klunky to me. It mixes up settings with
> control information. Maybe the control in
On Tue, Sep 28, 2010 at 12:46 AM, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 5:02 PM, Magnus Hagander wrote:
>> On Mon, Sep 27, 2010 at 08:34, Fujii Masao wrote:
>>> On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova
>>> wrote:
Maybe i'm missing something but this would be a problem if we
On Mon, Sep 27, 2010 at 5:02 PM, Magnus Hagander wrote:
> On Mon, Sep 27, 2010 at 08:34, Fujii Masao wrote:
>> On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova
>> wrote:
>>> Maybe i'm missing something but this would be a problem if we put a
>>> trigger file and the recovery.conf gets renamed to
On Mon, Sep 27, 2010 at 08:34, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova wrote:
>> Maybe i'm missing something but this would be a problem if we put a
>> trigger file and the recovery.conf gets renamed to recovery.done, no?
>> at least that would be a problem for the st
On Mon, Sep 27, 2010 at 08:52, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 10:55 AM, Robert Haas wrote:
>> Again, I think the real question is how to handle values that need to
>> be maintained PER SLAVE from values of which there is only one copy.
>
> Yep. One idea is to support something like
On 09/27/2010 10:08 AM, Robert Haas wrote:
The thing about the parameters for synchronous replication that is a
little different is that you need a whole set of parameters *for each
standby*. There's not a terribly clean way to handle that in
postgresql.conf as it exists today, but getting any a
On Mon, Sep 27, 2010 at 10:55 AM, Robert Haas wrote:
> Again, I think the real question is how to handle values that need to
> be maintained PER SLAVE from values of which there is only one copy.
Yep. One idea is to support something like "pg_ctl standby" and "pg_ctl pitr".
If we do so, we would
On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova wrote:
> Maybe i'm missing something but this would be a problem if we put a
> trigger file and the recovery.conf gets renamed to recovery.done, no?
> at least that would be a problem for the standbys that still need to
> be standbys
That's not prob
On Sun, Sep 26, 2010 at 9:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote:
>>> Yeah. The original design for recovery.conf envisioned that it has only
>>> a short lifespan while you're doing an archive recovery. Putting
>>> parameters for slave o
Robert Haas writes:
> On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote:
>> Yeah. The original design for recovery.conf envisioned that it has only
>> a short lifespan while you're doing an archive recovery. Putting
>> parameters for slave operation into it has contorted things beyond
>> recognit
On Sun, Sep 26, 2010 at 8:56 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote:
>>> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf.
>
>>> +1
>
Jaime Casanova writes:
> On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote:
>> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
>>> I noticed that there's no way to specify the location of recovery.conf
>>> in postgresql.conf.
>> +1
>>
>> That parameter would be useful when user makes multi
On Sun, Sep 26, 2010 at 6:29 PM, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
>> I noticed that there's no way to specify the location of recovery.conf
>> in postgresql.conf. The pg_hba and pg_ident files can be altered, so
>> I'm wondering why this file can't have a s
On Mon, Sep 27, 2010 at 6:56 AM, Thom Brown wrote:
> I noticed that there's no way to specify the location of recovery.conf
> in postgresql.conf. The pg_hba and pg_ident files can be altered, so
> I'm wondering why this file can't have a specified location. In
> Ubuntu, all configuration files a
Hi,
I noticed that there's no way to specify the location of recovery.conf
in postgresql.conf. The pg_hba and pg_ident files can be altered, so
I'm wondering why this file can't have a specified location. In
Ubuntu, all configuration files are in a different location to the
cluster by default, s
31 matches
Mail list logo
