On 06/30/2014 09:46 AM, Alvaro Herrera wrote:
> If we only had bricks and mortar, I think we would have a tool to
> display and tweak pg_control separately from emptying pg_xlog, rather
> than this odd separation between pg_controldata and pg_resetxlog, each
> of which do a mixture of those things. But we have a wall two thirds
> done already, so it seems to make more sense to me to continue forward
> rather than tear it down and start afresh. This patch is a natural
> extension of what we already have.
As I said previously, I disagree. Being able to set a system identifier
at runtime is useful for a variety of scenarios which do not involve
database surgery or the risk of wiping out your data; in fact, the only
bad thing you can do by changing the system id is break the replication
connection.
As such, tying a change in system id to pg_resetxlog is kind of like
having a combination dental floss dispenser and bazooka. "No, not
*that* trigger!"
It pretty much guarantees that the ability to change the systemid, which
could be a generally useful feature with all kinds of application for
HA, clusters and sharding, would remain an internal feature of BDR only,
because everyone else will be afraid to touch it.
If this means that we need to finally create pg_editcontroldata, then so
be it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com