On 24 December 2012 17:15, Andres Freund and...@2ndquadrant.com 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
On Thu, Jan 3, 2013 at 07:45:32PM +, Simon Riggs wrote:
On 3 January 2013 18:35, Josh Berkus j...@agliodbs.com 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
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 GUC
On 3 January 2013 18:35, Josh Berkus j...@agliodbs.com 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
On Mon, Dec 24, 2012 at 7:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
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
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
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*
On 23 December 2012 15:24, Fujii Masao masao.fu...@gmail.com 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
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 is
On 24 December 2012 15:48, Bruce Momjian br...@momjian.us 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
On Mon, Dec 24, 2012 at 03:57:10PM +, Simon Riggs wrote:
On 24 December 2012 15:48, Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
On 2012-12-24 18:06:44 +0100, Dimitri Fontaine wrote:
Bruce Momjian br...@momjian.us 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,
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 we
Josh Berkus j...@agliodbs.com 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
On Sat, Dec 22, 2012 at 5:14 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 21.12.2012 21:43, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjianbr...@momjian.us wrote:
It's not too complex. You just want that to be true. The original
developer has actually literally gone
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
problems
On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus j...@agliodbs.com 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 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
On 19 December 2012 22:19, Joshua Berkus j...@agliodbs.com wrote:
It stalled because the patch author decided not to implement the
request to detect recovery.conf
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us 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
On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs si...@2ndquadrant.com 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
On 21 December 2012 17:12, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 21, 2012 at 9:21 AM, Simon Riggs si...@2ndquadrant.com 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
On 21 December 2012 14:09, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 20, 2012 at 5:07 PM, Joshua Berkus j...@agliodbs.com 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,
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us 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
On 21 December 2012 19:21, Bruce Momjian br...@momjian.us wrote:
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
At this point backward compatibility has paralyzed us from fixing a
recovery.conf API that everyone
On Fri, Dec 21, 2012 at 07:32:48PM +, Simon Riggs wrote:
On 21 December 2012 19:21, Bruce Momjian br...@momjian.us wrote:
On Fri, Dec 21, 2012 at 02:25:47PM +, Simon Riggs wrote:
On 20 December 2012 19:29, Bruce Momjian br...@momjian.us wrote:
At this point backward compatibility
On 21 December 2012 19:35, Bruce Momjian br...@momjian.us 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
On Fri, Dec 21, 2012 at 07:43:29PM +, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjian br...@momjian.us 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
On 21.12.2012 21:43, Simon Riggs wrote:
On 21 December 2012 19:35, Bruce Momjianbr...@momjian.us 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,
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
On Wed, Dec 19, 2012 at 07:32:33PM -0500, Robert Haas wrote:
On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Dec 19, 2012 at 10:34:14PM +, Simon Riggs wrote:
On 19 December 2012 22:19, Joshua Berkus j...@agliodbs.com wrote:
It stalled because the patch author decided not to implement the
request to detect recovery.conf in data directory, which allows
backwards compatibility.
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
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, not
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 done
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
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 19 December 2012 06:10, Magnus Hagander mag...@hagander.net 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
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
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? (the
On 19 December 2012 22:19, Joshua Berkus j...@agliodbs.com 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 si...@2ndquadrant.com 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,
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 Dec 19, 2012 4:43 AM, Josh Berkus j...@agliodbs.com 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
45 matches
Mail list logo
