On 7/18/15 9:42 AM, Petr Jelinek wrote: > Well, last time I submitted this I did it exactly as you propose but > there was long discussion about this changing the target audience of > pg_resetxlog and that it would be better as separate binary from > pg_resetxlog.
In my reading of the thread, I did not get the sense that that was the consensus. There were certainly a lot of different opinions, but specifically some people ended up withdrawing their objections to using pg_resetxlog. > It might more future proof to have more generic binary which can do all > the less dangerous work that pg_resetxlog does (which currently is > probably only -c and the newly proposed -s). I don't buy the more or less dangerous argument. Many tools can be dangerous. cp can be dangerous if you overwrite the wrong file. pg_restore can be dangerous if you give it the wrong options. Changing the system ID is also dangerous, as it can break replication and truncate the WAL. Right now, changing the system ID is an obscure step in some obscure workflow related to some obscure feature. That is not to say it's invalid, but it's not something that we can present to a normal user as the official workflow. Just adding little tools of the nature "whack this around until it's in the right shape for this other thing" is just adding complications on top of complications. If we want to turn this into a less "dangerous" and more user-facing feature, I would like to see a complete workflow of how this would be used. Maybe we'll come up with a better solution. For example, why couldn't pg_basebackup take care of this? > Something like pg_setcontroldata but that's too long. Well, there is nothing so far saying that pg_controldata couldn't also write to pg_control. It's not called pg_getcontroldata. ;-) -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers