From: | Joshua Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Robert Treat <rob(at)xzilla(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: unite recovery.conf and postgresql.conf |
Date: | 2011-11-01 17:11:59 |
Message-ID: | 1485500873.110617.1320167519240.JavaMail.root@mail-1.01.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> forcing backwards compatibility on people who would much rather just
> do things the new way. Given that, I foresee a whole new generation
> of
> confused users who end up setting their configs one way only to have
> someone else set the same config in the other file, or some tool dump
> out some config file, overriding what was really intended. This will
> also make things *harder* for those tool providers you are trying to
> help, as they will be forced to support the behavior *both ways*. I'd
> much rather see some type of switch which turns on the old behavior
> for those who really want it, because while you can teach the new
> behavior, if you can't prevent the old behavior, you're creating
> operational headaches for yourself.
This is a good point. There's also the second drawback, which is complexity of code, which I believe that Tom Lane has brought up before; having two separate-but-equal paths for configuration is liable to lead to a lot of bugs.
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.
2) Offer backwards compatibility only if "recovery_conf='filename'" is set in postgresql.conf, then behave like Simon's compromise.
3) Simon's compromise.
4) Don't ever change how recovery.conf works.
The only two of the above I see as being real options are (1) and (2). (3) would, as Robert points out, cause DBAs to have unpleasant surprises when some third-party tool creates a recovery.conf they weren't expecting. So:
(1) pros:
* new, clean API
* makes everyone update their tools
* no confusion on "how to do failover"
* code simplicity
cons:
* breaks a bunch of 3rd-party tools
* or forces them to maintain separate 9.1 and 9.2 branches
(2) pros:
* allows people to use only new API if they want
* allows gradual update of tools
* can also lump in relocatable recovery.conf as feature
cons:
* puts off the day when vendors pay attention to the new API
(and even more kicking & screaming when that day comes)
* confusion about "how to do failover"
* code complexity
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-11-01 17:20:03 | Re: IDLE in transaction introspection |
Previous Message | Scott Mead | 2011-11-01 17:11:42 | Re: IDLE in transaction introspection |