On 24 December 2012 17:15, Andres Freund wrote:
>> On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
>> > From all of the above, I think its worth doing this
>> > * allowing recovery.conf to be in a different directory
>> > * make recovery config parameters into GUCs
>> > * no other ch
On Thu, Jan 3, 2013 at 07:45:32PM +, Simon Riggs wrote:
> On 3 January 2013 18:35, Josh Berkus wrote:
> > Robert,
> >
> >> In my view, the biggest problem with recovery.conf is that the
> >> parameters in there are not GUCs, which means that all of the
> >> infrastructure that we've built for
On 3 January 2013 18:35, Josh Berkus wrote:
> Robert,
>
>> In my view, the biggest problem with recovery.conf is that the
>> parameters in there are not GUCs, which means that all of the
>> infrastructure that we've built for managing GUCs does not work with
>> them. As an example, when we conver
Robert,
> In my view, the biggest problem with recovery.conf is that the
> parameters in there are not GUCs, which means that all of the
> infrastructure that we've built for managing GUCs does not work with
> them. As an example, when we converted recovery.conf to use the same
> lexer that the G
On Wed, Dec 26, 2012 at 3:32 PM, Josh Berkus wrote:
>> There already are two ways to promote a server out of recovery. One is
>> creating the trigger file. The other is "pg_ctl promote". (it uses a
>> trigger file called $PGDATA/promote internally, but that's invisible to
>> the user).
>
> Right,
There already are two ways to promote a server out of recovery. One is
creating the trigger file. The other is "pg_ctl promote". (it uses a
trigger file called $PGDATA/promote internally, but that's invisible to
the user).
Right, I was thinking of the trigger file to put a server *into*
repli
On 26.12.2012 21:55, Josh Berkus wrote:
I'm not sure that my POV exactly matches up with Tom's, but on the
last point, I strongly agree that the use of the trigger file makes it
trivial to integrate Postgres warm standby management into 3rd party
tools. I'm not against coming up with a new API
I'm not sure that my POV exactly matches up with Tom's, but on the
last point, I strongly agree that the use of the trigger file makes it
trivial to integrate Postgres warm standby management into 3rd party
tools. I'm not against coming up with a new API that's better for
postgres dedicated tool
On Mon, Dec 24, 2012 at 7:04 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> What the patch doesn't change is the requirement to have a file that
>>> causes the server to place itself into archive recovery. So there is
>>> no more recovery.conf and instead we have a file called
>>> recovery.trigger
Josh Berkus writes:
>> What the patch doesn't change is the requirement to have a file that
>> causes the server to place itself into archive recovery. So there is
>> no more recovery.conf and instead we have a file called
>> recovery.trigger instead.
> Requiring a file in order to make a server
Simon,
> What the patch doesn't change is the requirement to have a file that
> causes the server to place itself into archive recovery. So there is
> no more recovery.conf and instead we have a file called
> recovery.trigger instead.
Requiring a file in order to make a server a replica is what w
On 2012-12-24 18:06:44 +0100, Dimitri Fontaine wrote:
> Bruce Momjian writes:
> > Is that what everyone else wants? If that is all, let's do it and close
> > the item.
>
> What Simon is proposing is quite clear and not what you pasted, if I'm
> reading that correctly:
>
> On Mon, Dec 24, 2012 at
Bruce Momjian writes:
> Is that what everyone else wants? If that is all, let's do it and close
> the item.
What Simon is proposing is quite clear and not what you pasted, if I'm
reading that correctly:
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
> From all of the above, I thin
On Mon, Dec 24, 2012 at 03:57:10PM +, Simon Riggs wrote:
> On 24 December 2012 15:48, Bruce Momjian wrote:
> > On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
> >> I don't think that represents enough change to keep people happy, but
> >> I don't see anything else useful being sug
On 24 December 2012 15:48, Bruce Momjian wrote:
> On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
>> I don't think that represents enough change to keep people happy, but
>> I don't see anything else useful being suggested in this patch. Other
>> design thoughts welcome, but personall
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
> I don't think that represents enough change to keep people happy, but
> I don't see anything else useful being suggested in this patch. Other
> design thoughts welcome, but personally, I think rushing this design
> through at this stage
On 23 December 2012 15:24, Fujii Masao wrote:
> The latest patch is the following. Of course, this cannot be applied
> cleanly in HEAD.
> http://archives.postgresql.org/message-id/CAHGQGwHB==cjehme6jiuy-knutrx-k3ywqzieg1gpnb3ck6...@mail.gmail.com
>
>> Just by looking at the last few posts, this s
On Sat, Dec 22, 2012 at 5:14 AM, Heikki Linnakangas
wrote:
> On 21.12.2012 21:43, Simon Riggs wrote:
>>
>> On 21 December 2012 19:35, Bruce Momjian wrote:
>>
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of
> Forgive me because I have been up for 28 hours on a 9.0 to 9.2 migration
> with Hot Standby and PgPool-II for load balancing but I was excessively
> irritated that I had to go into recovery.conf to configure things. I am
> one of the software authors that breaking recovery.conf will cause
> prob
On 12/21/2012 11:56 AM, Bruce Momjian wrote:
That is where we are now. Overhauling recovery.conf can't be a
super-complex job, and we already have a patch we can base it of off.
Why is this not done yet! I don't know, but I have seen lots of
discussion about it, and no clear conclusions, at l
On 21.12.2012 21:43, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjian wrote:
It's not too complex. You just want that to be true. The original
developer has actually literally gone away, but not because of this.
Well, Robert and I remember it differently.
Anyway, I will ask for a
On Fri, Dec 21, 2012 at 07:43:29PM +, Simon Riggs wrote:
> On 21 December 2012 19:35, Bruce Momjian wrote:
>
> >> It's not too complex. You just want that to be true. The original
> >> developer has actually literally gone away, but not because of this.
> >
> > Well, Robert and I remember it
On 21 December 2012 19:35, Bruce Momjian wrote:
>> It's not too complex. You just want that to be true. The original
>> developer has actually literally gone away, but not because of this.
>
> Well, Robert and I remember it differently.
>
> Anyway, I will ask for a vote now.
And what will you as
On Fri, Dec 21, 2012 at 07:32:48PM +, Simon Riggs wrote:
> On 21 December 2012 19:21, Bruce Momjian wrote:
> > On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
> >> On 20 December 2012 19:29, Bruce Momjian wrote:
> >>
> >> > At this point backward compatibility has paralyzed us fr
On 21 December 2012 19:21, Bruce Momjian wrote:
> On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
>> On 20 December 2012 19:29, Bruce Momjian wrote:
>>
>> > At this point backward compatibility has paralyzed us from fixing a
>> > recovery.conf API that everyone agrees is non-optimal,
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
> On 20 December 2012 19:29, Bruce Momjian wrote:
>
> > At this point backward compatibility has paralyzed us from fixing a
> > recovery.conf API that everyone agrees is non-optimal, and this has
> > gone on for multiple major releases.
On 21 December 2012 14:09, Robert Haas wrote:
> On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus wrote:
>>> As ever, we spent much energy on debating backwards compatibility
>>> rather than just solving the problem it posed, which is fairly easy
>>> to
>>> solve.
>>
>> Well, IIRC, the debate was pr
On 21 December 2012 17:12, Robert Haas wrote:
> On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs wrote:
>> No, lets not.
>>
>> The only stall happening is because of a refusal to listen to another
>> person's reasonable request during patch review. That requirement is
>> not a blocker to the idea, it
On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs wrote:
> No, lets not.
>
> The only stall happening is because of a refusal to listen to another
> person's reasonable request during patch review. That requirement is
> not a blocker to the idea, it just needs to be programmed.
>
> Lets just implement
On 20 December 2012 19:29, Bruce Momjian wrote:
> At this point backward compatibility has paralized us from fixing a
> recovery.conf API that everyone agrees is non-optimal, and this has
> gone on for multiple major releases. I don't care what we have to do,
> just clean this up for 9.3!
The m
On 20 December 2012 19:29, Bruce Momjian wrote:
> On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
>> On 19 December 2012 22:19, Joshua Berkus wrote:
>> >
>> >> It stalled because the patch author decided not to implement the
>> >> request to detect recovery.conf in data directory, wh
On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus wrote:
>> As ever, we spent much energy on debating backwards compatibility
>> rather than just solving the problem it posed, which is fairly easy
>> to
>> solve.
>
> Well, IIRC, the debate was primarily of *your* making. Almost everyone else
> on t
Andreas,
> Do you want the node one step up or the top-level in the chain?
> Because
> I don't think we can do the latter without complicating the
> replication
> protocol noticably.
Well, clearly a whole chain would be nice for the user. But even just one step
up would be very useful.
--Josh
On 2012-12-18 19:43:09 -0800, Josh Berkus wrote:
> We should probably have a function, like pg_replication_master(), which
> gives the host address of the current master. This would help DBAs for
> large replication clusters a lot. Obviously, this would only work in
> streaming.
Do you want the
> As ever, we spent much energy on debating backwards compatibility
> rather than just solving the problem it posed, which is fairly easy
> to
> solve.
Well, IIRC, the debate was primarily of *your* making. Almost everyone else on
the thread was fine with the original patch, and it was nearly d
> Let me also add that I am tired of having recovery.conf improvement
> stalled by backward compatibility concerns. At this point, let's just
> trash recovery.conf backward compatibility and move on.
>
> And I don't want to hear complaints about tool breakage either. These are
> external tools,
On Thu, Dec 20, 2012 at 02:29:49PM -0500, Bruce Momjian wrote:
> Let me also add that I am tired of having recovery.conf improvement
> stalled by backward compatibility concerns. At this point, let's just
> trash recovery.conf backward compatibility and move on.
>
> And I don't want to hear co
On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
> On 19 December 2012 22:19, Joshua Berkus wrote:
> >
> >> It stalled because the patch author decided not to implement the
> >> request to detect recovery.conf in data directory, which allows
> >> backwards compatibility.
> >
> > Well,
On Wed, Dec 19, 2012 at 07:32:33PM -0500, Robert Haas wrote:
> On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs wrote:
> > As ever, we spent much energy on debating backwards compatibility
> > rather than just solving the problem it posed, which is fairly easy to
> > solve.
>
> I'm still of the opini
On Thursday, December 20, 2012 3:50 AM Joshua Berkus wrote:
>
> > It stalled because the patch author decided not to implement the
> > request to detect recovery.conf in data directory, which allows
> > backwards compatibility.
>
> Well, I don't think we had agreement on how important backwards
>
On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs wrote:
> As ever, we spent much energy on debating backwards compatibility
> rather than just solving the problem it posed, which is fairly easy to
> solve.
I'm still of the opinion (as were a lot of people on the previous
thread, IIRC) that just makin
On 19 December 2012 22:19, Joshua Berkus wrote:
>
>> It stalled because the patch author decided not to implement the
>> request to detect recovery.conf in data directory, which allows
>> backwards compatibility.
>
> Well, I don't think we had agreement on how important backwards compatibility
>
> This sounds like my previous suggestion of returning the primary
> conninfo value, but with just ip. That one came with a pretty bad
> patch, and was later postponed until we folded recovery.conf into
> the main configuration file parsing. I'm not really sure what
> happened to that project? (th
> It stalled because the patch author decided not to implement the
> request to detect recovery.conf in data directory, which allows
> backwards compatibility.
Well, I don't think we had agreement on how important backwards compatibility
for recovery.conf was, particularly not on the whole
reco
On 19 December 2012 06:10, Magnus Hagander wrote:
> This sounds like my previous suggestion of returning the primary conninfo
> value, but with just ip. That one came with a pretty bad patch, and was
> later postponed until we folded recovery.conf into the main configuration
> file parsing. I'm n
On Dec 19, 2012 4:43 AM, "Josh Berkus" wrote:
>
> Hackers,
>
> Currently we can see each master's current replicas using
> pg_stat_replication. However, there is no way from a replica, that I
> know of, to figure out who its master is other than to look at
> recovery.conf.
>
> We should probably
Hackers,
Currently we can see each master's current replicas using
pg_stat_replication. However, there is no way from a replica, that I
know of, to figure out who its master is other than to look at
recovery.conf.
We should probably have a function, like pg_replication_master(), which
gives the
47 matches
Mail list logo
