On 10 May 2012 05:44, Josh Berkus j...@agliodbs.com wrote:
I expect to revisit config directories before the first 9.3 CF, it will
help multiple things I'd like to see happen. Then we can circle back to
the main unification job with a fairly clear path forward from there.
Yeah, let's
A key requirement is to be able to drop in new config files without
needing to $EDIT anything.
Yes, absolutely. I want to move towards the idea that the majority of
our users never edit postgresql.conf by hand.
OK, its possible to put in lots of includeifexists for non-existent
files just
All,
I'll point out that this patch got sandbagged to death, and never made
it into 9.2. So, for 9.2 replication is just as hard to configure and
manage as it was in 9.1. Are we going to fix it in 9.3, or not?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via
On Wed, May 09, 2012 at 08:07:52PM -0700, Josh Berkus wrote:
All,
I'll point out that this patch got sandbagged to death, and never made
it into 9.2. So, for 9.2 replication is just as hard to configure and
manage as it was in 9.1. Are we going to fix it in 9.3, or not?
Greg Smith was
On 05/09/2012 11:15 PM, Bruce Momjian wrote:
On Wed, May 09, 2012 at 08:07:52PM -0700, Josh Berkus wrote:
All,
I'll point out that this patch got sandbagged to death, and never made
it into 9.2. So, for 9.2 replication is just as hard to configure and
manage as it was in 9.1. Are we going to
I expect to revisit config directories before the first 9.3 CF, it will
help multiple things I'd like to see happen. Then we can circle back to
the main unification job with a fairly clear path forward from there.
Yeah, let's discuss this next week. Easier configuration is one
demand I'm
Greg,
You keep asking the hard questions.
I practice. ;-)
Right now, I kind of like that it's
possible to copy a postgresql.conf file from master to standby and just
use it. That should still be possible with the realignment into GUCs:
... long discussion omitted here.
I agree that GUC
On Wed, Dec 14, 2011 at 8:56 PM, Josh Berkus j...@agliodbs.com wrote:
So for streaming replication, will I need to have a standby.enabled
file, or will there be a parameter in postgresql.conf (or included
files) which controls whether or not that server is a standby, available?
In the best of
I've submitted two patches for adding new include features to the
postgresql.conf file. While not quite commit quality yet, I hope
everyone will agree their reviews this week suggest both are close
enough that any number of people could finish them off. Before
re-opening this can of worms, I
On Wed, Dec 14, 2011 at 4:16 PM, Greg Smith g...@2ndquadrant.com wrote:
[ plan for deprecating recovery.conf ]
+1. I'd be very happy with this plan.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
On Wed, Dec 14, 2011 at 22:16, Greg Smith g...@2ndquadrant.com wrote:
I've submitted two patches for adding new include features to the
postgresql.conf file. While not quite commit quality yet, I hope everyone
will agree their reviews this week suggest both are close enough that any
number of
On 12/14/11 1:16 PM, Greg Smith wrote:
-Creating a standby.enabled file in the directory that houses the
postgresql.conf (same logic as include uses to locate things) puts the
system into recovery mode. That feature needs to save some state, and
making those decisions based on existence of
On 12/14/2011 04:47 PM, Magnus Hagander wrote:
You say the server can just delete it. But how will this work if the
file is *not* in the data directory? If you are on a Debian style
system for example, where all these files go in /etc/postgresql -
wouldn't that suddenly require the postgres user
On 12/14/2011 04:57 PM, Josh Berkus wrote:
How will things work for PITR?
Left that out mainly because I was already running too long there, but I
do think there's a reasonable path. There is one additional wrinkle in
there to consider that I've thought of so far, falling into the what is
Greg,
Put the stuff you used to insert into recovery.conf into postgresql.conf
instead. If you don't like that, use another file and include it with
one of the multiple options for that--same migration option I already
suggested. Run pg_ctl recovery; under the hood that's actually
creating
On 12/14/2011 08:56 PM, Josh Berkus wrote:
So for streaming replication, will I need to have a standby.enabled
file, or will there be a parameter in postgresql.conf (or included
files) which controls whether or not that server is a standby, available?
In the best of all possible worlds, I'd
All:
*ping*
Trying to restart this discussion, since the feature bogged down on
spec. We have consensus that we need to change how replication mode is
mangaged; surely we can reach consensus on how to change it?
On 11/8/11 11:39 AM, Josh Berkus wrote:
configuration data somewhere else, but
On Mon, Nov 7, 2011 at 2:14 PM, Josh Berkus j...@agliodbs.com wrote:
2. standby_mode becomes an ENUM: off,standby,pitr. It can be reset on
server reload or through pg_ctl promote
I'm a little bit confused by the way we're dragging standby_mode into
this conversation. If you're using
configuration data somewhere else, but we really need to be able to tell
the difference between starting PITR, continuing PITR after a
mid-recovery crash, and finished PITR, up and running normally.
A GUC is not a good way to do that.
Does a GUC make sense to you for how to handle
Agreed. This thread has already expended too much of our valuable time,
in my opinion.
As I said elsewhere, I think that a modified version of Simon's proposal
gets us all what we want except code cleanliness. I'd like to hear from
Tom on that issue.
The proposal is:
1. No changes are
Josh Berkus j...@agliodbs.com writes:
As I said elsewhere, I think that a modified version of Simon's proposal
gets us all what we want except code cleanliness. I'd like to hear from
Tom on that issue.
Well, code complexity is hard to gauge without coding a draft
implementation, but I think
Josh Berkus wrote:
We can always do nothing, which is a safe and viable option.
Not really, no. The whole recovery.conf thing is very broken and
inhibits adoption of PostgreSQL because our users can't figure it out.
You've made it pretty clear that you're personally comfortable with how
On 09/24/2011 04:49 PM, Joshua Berkus wrote:
Well, we *did* actually come up with a reasonable way, but it died
under an avalanche of bikeshedding and
we-must-do-everything-the-way-we-always-have-done. I refer, of
course, to the configuration directory patch, which was a fine
solution, and
On Wed, Nov 2, 2011 at 1:45 AM, Robert Haas robertmh...@gmail.com wrote:
I think that might have some possibilities. But how does that work in
detail?
My thoughts also. I want to see the detail on an alternate proposal so
we can decide things sensibly.
--
Simon Riggs
On Wed, Nov 2, 2011 at 1:11 AM, Josh Berkus j...@agliodbs.com wrote:
There is no way we're getting distro packagers to switch from pg_ctl
start. Also, a lot of distros use the postgres command rather than
pg_ctl anything.
So backwards compatibility is important for downstream software.
--
On Wed, Nov 2, 2011 at 1:11 AM, Josh Berkus j...@agliodbs.com wrote:
There is no way we're getting distro packagers to switch from pg_ctl
start. Also, a lot of distros use the postgres command rather than
pg_ctl anything.
So backwards compatibility is important for downstream software.
--
RH, Simon,
I think that might have some possibilities. But how does that work in
detail? If you set it to empty, then the recovery_* parameters are
just GUCs, I suppose: which seems fine. But if you set it to a
non-empty value then what happens, exactly? The recovery.conf
settings
On Wed, Nov 2, 2011 at 2:48 PM, Josh Berkus j...@agliodbs.com wrote:
Is anyone working on SET PERSISTENT? I thought that got bike-shedded to
death.
I think we had a fairly good sketch of how it could work mapped out,
mostly based around adding a postgresql.auto file. I could dig up the
old
On Wed, Nov 2, 2011 at 6:48 PM, Josh Berkus j...@agliodbs.com wrote:
Well, as someone who sets up and admins replication for a bunch of
clients, here's what I'd like to see:
Everyone has their own set of requirements. I've tried hard to fuse
those together into a useful proposal, listening to
Simon,
Everyone has their own set of requirements. I've tried hard to fuse
those together into a useful proposal, listening to all. Please bear
in mind that I make my living in exactly the same way you do, so you
must surely be aware I do this solely in the common interest.
Thank you for
On Mon, Oct 31, 2011 at 5:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2 the presence of recovery.conf can and therefore should continue
to act as it does in 9.1.
This means that recovery.conf is renamed to
On Tue, Nov 1, 2011 at 5:59 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Oct 31, 2011 at 5:23 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2 the presence of recovery.conf can and therefore should continue
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you change a parameter that only has effect during recovery then
must get an error if it is changed during normal running.
I don't see why. If you're in normal running and someone changes a
parameter that is irrelevant
On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you change a parameter that only has effect during recovery then
must get an error if it is changed during normal running.
I don't see why. If
On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
If you change a parameter that only has effect during recovery then
must
On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs si...@2ndquadrant.com wrote:
Why do we have this log message then, if it is OK to ignore changes
that have no effect?
LOG: parameter shared_buffers cannot be changed without restarting the
server
I believe we're logging the fact that we were
On Tue, Nov 1, 2011 at 1:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 8:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 12:06 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 7:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 2:04 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 1, 2011 at 9:45 AM, Simon Riggs si...@2ndquadrant.com wrote:
Why do we have this log message then, if it is OK to ignore changes
that have no effect?
LOG: parameter shared_buffers cannot be changed without
On Tue, Nov 1, 2011 at 6:36 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/1/11 10:34 AM, Simon Riggs wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop
On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat r...@xzilla.net wrote:
On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards
Robert,
In most cases we either break backwards compatibility or require some
type of switch to turn on backwards compatibility for those who want
it. While the above plan tries to do one better, it leaves me feeling
that the thing I don't like about this is that it sounds like you are
On 11/1/11 10:34 AM, Simon Riggs wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop supporting recovery.conf
as a trigger file at all.
Note that is
On Tue, Nov 1, 2011 at 2:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 6:12 PM, Robert Treat r...@xzilla.net wrote:
On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we
On Tue, Nov 1, 2011 at 1:34 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop supporting recovery.conf
as a trigger
On Tue, Nov 1, 2011 at 5:11 PM, Joshua Berkus j...@agliodbs.com wrote:
So, we have four potential paths regarding recovery.conf:
1) Break backwards compatibility entirely, and stop supporting recovery.conf
as a trigger file at all.
Note that is exactly what I have suggested when using
On 11/1/11 12:29 PM, Robert Treat wrote:
Starting in 9.2, you should use pg_ctl standby to launch your
database for normal operations and/or in cases where you are writing
init scripts to control your production databases. For backwards
compatibility, if you require the old behavior of using a
On Tue, Nov 1, 2011 at 9:11 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/1/11 12:29 PM, Robert Treat wrote:
Starting in 9.2, you should use pg_ctl standby to launch your
database for normal operations and/or in cases where you are writing
init scripts to control your production databases.
On Sat, Oct 29, 2011 at 7:54 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Sep 9, 2011 at 10:56 AM, Fujii Masao masao.fu...@gmail.com wrote:
In previous discussion, we've reached the consensus that we should unite
recovery.conf and postgresql.conf. The attached patch does that. The
On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.2 the presence of recovery.conf can and therefore should continue
to act as it does in 9.1.
This means that recovery.conf is renamed to recovery.done at the end of
recovery. IOW, all settings in recovery.conf are
Simon,
Everybody agrees a neater way of invoking standby mode would be good.
I don't think this goes far enough. The whole
recovery.conf/recovery.done thing is a serious problem for automated
management of servers and automated failover. So it's not just a
neater way would be good but using
On Mon, Oct 31, 2011 at 7:05 PM, Josh Berkus j...@agliodbs.com wrote:
If it's possible to run a replica without having a recovery.conf file,
then I'm fine with your solution. If it's not, then I find your
solution not to be a solution at all.
Then you are fine with the solution - not mine
On Mon, Oct 31, 2011 at 3:19 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 31, 2011 at 7:05 PM, Josh Berkus j...@agliodbs.com wrote:
If it's possible to run a replica without having a recovery.conf file,
then I'm fine with your solution. If it's not, then I find your
solution not
On Fri, Sep 9, 2011 at 10:56 AM, Fujii Masao masao.fu...@gmail.com wrote:
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 to update the document, but if you notice something,
Simon,
I haven't see a response from you on a proposed way to keep backwards
compatibility with recovery.conf as a trigger file, while also
eliminating its trigger status as an unmanagable misfeature. As far as
I can tell, that's the one area where we *cannot* maintain backwards
compatibility.
Fujii Masao wrote:
On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus j...@agliodbs.com wrote:
Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
provide parameters solely for recovery. That is difficult
On 10/10/11 9:53 PM, Fujii Masao wrote:
Or you think that, to keep the backward compatibility completely,
recovery.conf should be used as not only a configuration file but also a
recovery trigger one and it should be renamed to recovery.done at
the end of recovery?
That's precisely my point.
On Tue, Oct 11, 2011 at 3:29 PM, Bruce Momjian br...@momjian.us wrote:
As much as I appreciate Simon's work in this area, I think we are still
unclear if keeping backward-compatibility is worth the complexity
required for future users. Historically we have been bold in changing
Simon Riggs wrote:
On Tue, Oct 11, 2011 at 3:29 PM, Bruce Momjian br...@momjian.us wrote:
As much as I appreciate Simon's work in this area, I think we are still
unclear if keeping backward-compatibility is worth the complexity
required for future users. ?Historically we have been bold in
On Tue, Oct 11, 2011 at 9:28 PM, Bruce Momjian br...@momjian.us wrote:
Standard conforming strings
was tricky because it was more user-facing, or certainly SQL-facing.
Why is SQL more important than backup?
There is no good reason to do this so quickly.
--
Simon Riggs
Simon Riggs wrote:
On Tue, Oct 11, 2011 at 9:28 PM, Bruce Momjian br...@momjian.us wrote:
Standard conforming strings
was tricky because it was more user-facing, or certainly SQL-facing.
Why is SQL more important than backup?
Because the percentage of database users it affects is
Simon,
Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
provide parameters solely for recovery. That is difficult to do
without causing all downstream tools to make major changes in the ways
they supply parameters.
Actually, this case is easily solved by an include
On 10/10/11 10:52 AM, Josh Berkus wrote:
So after debugging some of our failover scripts, here's the real-world
problems I'm trying to solve. These design flaws are issues which cause
automated failover or failback to abort, leading to unexpected downtime,
so they are not just issues of
On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus j...@agliodbs.com wrote:
Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
provide parameters solely for recovery. That is difficult to do
without causing all downstream tools to make major changes in the ways
they supply
On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus j...@agliodbs.com wrote:
Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
provide parameters solely for recovery. That is difficult to do
without causing
On Tue, Sep 27, 2011 at 10:34 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 26, 2011 at 7:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2011-09-25 at 12:58 -0400, Tom Lane wrote:
And it's not like we don't break configuration file
contents in most releases anyway, so I
On Tue, Sep 27, 2011 at 1:33 AM, Fujii Masao masao.fu...@gmail.com wrote:
Though there is still ongonig discussion, since there is no objection about
the above two changes, I revised the patch that way. And I fixed the minor
bug handling the default value of recovery_target_timeline wrongly.
On Mon, Sep 26, 2011 at 7:45 PM, Peter Eisentraut pete...@gmx.net wrote:
On sön, 2011-09-25 at 12:58 -0400, Tom Lane wrote:
And it's not like we don't break configuration file
contents in most releases anyway, so I really fail to see why this one
has suddenly become sacrosanct.
Well, there
On lör, 2011-09-24 at 13:04 -0400, Tom Lane wrote:
What if we modified pg_ctl to allow passing configuration parameters
through to postmaster,
You mean like pg_ctl -o?
Note that pg_ctl -o saves the parameters it uses and reapplies them
after a restart. So this is not really the way to
On lör, 2011-09-24 at 14:02 +0100, Simon Riggs wrote:
The semantics are clear: recovery.conf is read first, then
postgresql.conf. It's easy to implement (1 line of code) and easy to
understand.
What's clear about that? My intuition would have been that
recovery.conf is read second.
--
Sent
On sön, 2011-09-25 at 12:58 -0400, Tom Lane wrote:
And it's not like we don't break configuration file
contents in most releases anyway, so I really fail to see why this one
has suddenly become sacrosanct.
Well, there is a slight difference. Changes in postgresql.conf
parameter names and
On 09/25/2011 02:39 PM, Joshua Berkus wrote:
There might be a use case for a separate directive include_if_exists,
or some such name. But I think the user should have to tell us very
clearly that it's okay for the file to not be found.
Better to go back to include_directory, then.
I
On Sat, Sep 24, 2011 at 3:49 PM, Joshua Berkus j...@agliodbs.com wrote:
Since we haven't yet come up with a reasonable way of machine-editing
postgresql.conf, this seems like a fairly serious objection to
getting
rid of recovery.conf. I wonder if there's a way we can work around
that...
Simon Riggs si...@2ndquadrant.com writes:
On Sat, Sep 24, 2011 at 6:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Okay, so you do agree that eventually we want to be rid of
recovery.conf? I think everyone else agrees on that. But if we are
going to remove recovery.conf eventually, what is the
Robert Haas robertmh...@gmail.com writes:
On Sep 24, 2011, at 1:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't exactly buy this argument. If postgresql.conf is hard to
machine-edit, why is recovery.conf any easier?
Because you generally just write a brand-new file, without worrying
about
Folks,
What happens currently if we have an \include in postgresql.conf for a file
which doesn't exist? Is it ignored, or do we error out?
If it could just be ignored, maybe with a note in the logs, then we could be a
lot more flexible.
--Josh Berkus
--
Sent via pgsql-hackers mailing list
Joshua Berkus j...@agliodbs.com writes:
What happens currently if we have an \include in postgresql.conf for a file
which doesn't exist? Is it ignored, or do we error out?
It's an error, and I think changing that would be a really bad idea.
If it could just be ignored, maybe with a note in
There might be a use case for a separate directive include_if_exists,
or some such name. But I think the user should have to tell us very
clearly that it's okay for the file to not be found.
Better to go back to include_directory, then.
--Josh Berkus
--
Sent via pgsql-hackers mailing
I rather like Tom's suggestion of include_if_exists.
include_if_exists certainly solves the recovery.conf/recovery.done problem. We
can even phase it out, like this:
9.2: include_if_exists = 'recovery.conf' in the default postgresql.conf file.
9.3: include_if_exists = 'recovery.conf'
Joshua Berkus j...@agliodbs.com writes:
include_if_exists certainly solves the recovery.conf/recovery.done problem.
We can even phase it out, like this:
9.2: include_if_exists = 'recovery.conf' in the default postgresql.conf file.
9.3: include_if_exists = 'recovery.conf' commented out by
On Fri, Sep 23, 2011 at 5:51 PM, Josh Berkus j...@agliodbs.com wrote:
Simon,
There are many. Tools I can name include pgpool, 2warm, PITRtools, but
there are also various tools from Sun, an IBM reseller I have
forgotten the name of, OmniTI and various other backup software
providers. Those
On Fri, Sep 23, 2011 at 6:17 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 23, 2011 at 12:51 PM, Josh Berkus j...@agliodbs.com wrote:
I'm happy to make upgrades easier, but I want a path which eventually
ends in recovery.conf going away. It's a bad API, confuses our users,
and is
I'm not sure what you mean by not deal with but part of pgpool-II's
functionality assumes that we can easily generate recovery.conf. If
reconf.conf is integrated into postgresql.conf, we need to edit
postgresql.conf, which is a little bit harder than generating
recovery.conf, I think.
Oh?
On Sat, Sep 24, 2011 at 9:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
The semantics are clear: recovery.conf is read first, then
postgresql.conf. It's easy to implement (1 line of code) and easy to
understand.
Eh, well, if you can implement it in one line of code, consider my
objection
On Fri, Sep 23, 2011 at 6:55 PM, Tatsuo Ishii is...@postgresql.org wrote:
There are many. Tools I can name include pgpool, 2warm, PITRtools, but
there are also various tools from Sun, an IBM reseller I have
forgotten the name of, OmniTI and various other backup software
providers. Those are
Simon Riggs si...@2ndquadrant.com writes:
... The time to replace it is now and I
welcome that day and have already agreed to it.
Okay, so you do agree that eventually we want to be rid of
recovery.conf? I think everyone else agrees on that. But if we are
going to remove recovery.conf
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 23, 2011 at 6:55 PM, Tatsuo Ishii is...@postgresql.org wrote:
I'm not sure what you mean by not deal with but part of pgpool-II's
functionality assumes that we can easily generate recovery.conf. If
reconf.conf is integrated into
On Sep 24, 2011, at 1:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't exactly buy this argument. If postgresql.conf is hard to
machine-edit, why is recovery.conf any easier?
Because you generally just write a brand-new file, without worrying about
preserving existing settings. You aren't
On Sat, Sep 24, 2011 at 6:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
... The time to replace it is now and I
welcome that day and have already agreed to it.
Okay, so you do agree that eventually we want to be rid of
recovery.conf? I think everyone
Since we haven't yet come up with a reasonable way of machine-editing
postgresql.conf, this seems like a fairly serious objection to
getting
rid of recovery.conf. I wonder if there's a way we can work around
that...
Well, we *did* actually come up with a reasonable way, but it died under
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
On Tue, Sep 20, 2011 at 5:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
On 09/20/2011 09:23 AM, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
I sympathise with this view, to an extent.
If we do an automatic include of recovery.conf first, then follow by
reading postgresql,conf then we will preserve the old as well as
allowing the new.
I don't
Simon,
There are many. Tools I can name include pgpool, 2warm, PITRtools, but
there are also various tools from Sun, an IBM reseller I have
forgotten the name of, OmniTI and various other backup software
providers. Those are just the ones I can recall quickly. We've
encouraged people to
On Fri, Sep 23, 2011 at 12:51 PM, Josh Berkus j...@agliodbs.com wrote:
I'm happy to make upgrades easier, but I want a path which eventually
ends in recovery.conf going away. It's a bad API, confuses our users,
and is difficult to support and maintain.
I agree.
GUC = Grand Unified
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
Josh,
There are many. Tools I can name include pgpool, 2warm, PITRtools, but
there are also various tools from Sun, an IBM reseller I have
forgotten the name of, OmniTI and various other backup software
providers. Those are just the ones I can recall quickly. We've
encouraged people to write
I'm not sure what you mean by not deal with but part of pgpool-II's
functionality assumes that we can easily generate recovery.conf. If
reconf.conf is integrated into postgresql.conf, we need to edit
postgresql.conf, which is a little bit harder than generating
recovery.conf, I think.
Oh?
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 misleading
On Wed, Sep 21, 2011 at 12:55 PM, Josh Berkus j...@agliodbs.com 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
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
1 - 100 of 146 matches
Mail list logo
