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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
