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 least that you agree
with. I have realized this could languish for another two years unless
I stand up, say the old car is dead, and force us to get a new car!
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 for. Break it anyway.
The fact that anyone has to touch recovery.conf is at this point in
software development, backwards. No matter how it gets implemented it
shouldn't be anymore complicated than:
Master:
SET/ENABLE replication FOR db1;
Standby:
SET/ENABLE hot_standby MASTER db0
Have the logs automatically go to an archive tablespace (so it can be moved)
Now I am not expecting this to happen or even saying it is a valid
approach. What I am saying is that it should be "THAT" easy [1].
[2] Multi version rpms on the same box still need some help (lib issues)
[3] Bruce, you rock... pg_ugrade is the bomb
Joshua D. Drake
1. Obviously I am talking about the simplest of configuration and there
are a whole slew of other options that needs to be set but have
reasonable defaults.
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
