Re: [HACKERS] pg_resetsysid
On 2015-07-18 02:29, Peter Eisentraut wrote: On 6/14/15 11:29 AM, Petr Jelinek wrote: 0002 - Adds pg_resetsysid utility which changes the system id to newly generated one. 0003 - Adds -s option to pg_resetxlog to change the system id to the one specified - this is separate from the other one as it can be potentially more dangerous. Adding a new top-level binary creates a lot of maintenance overhead (e.g., documentation, man page, translations, packaging), and it seems silly to create a new tool whose only purpose is to change one number in one file. If we're going to have this in pg_resetxlog anyway, why not create another option letter to assigns a generated ID? As the documentation says, resetting the system ID clears the WAL, so it's not like this is a completely danger-free situation. 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. 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). Something like pg_setcontroldata but that's too long. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_resetsysid
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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_resetsysid
On 6/14/15 11:29 AM, Petr Jelinek wrote: 0002 - Adds pg_resetsysid utility which changes the system id to newly generated one. 0003 - Adds -s option to pg_resetxlog to change the system id to the one specified - this is separate from the other one as it can be potentially more dangerous. Adding a new top-level binary creates a lot of maintenance overhead (e.g., documentation, man page, translations, packaging), and it seems silly to create a new tool whose only purpose is to change one number in one file. If we're going to have this in pg_resetxlog anyway, why not create another option letter to assigns a generated ID? As the documentation says, resetting the system ID clears the WAL, so it's not like this is a completely danger-free situation. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
