From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_resetsysid |
Date: | 2015-07-18 13:42:38 |
Message-ID: | 55AA57CE.4020400@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2015-07-18 14:38:53 | Re: BRIN index and aborted transaction |
Previous Message | Michael Paquier | 2015-07-18 13:22:10 | Re: WAL test/verification tool |