Message-ID: <55AAE3E4.1090309@gmx.net>
Date: Sat, 18 Jul 2015 19:40:20 -0400
From: Peter Eisentraut <peter_e@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Petr Jelinek <petr@2ndquadrant.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: pg_resetsysid
References: <557D9DED.2080204@2ndquadrant.com> <55A99E07.3050905@gmx.net>
 <55AA57CE.4020400@2ndquadrant.com>
In-Reply-To: <55AA57CE.4020400@2ndquadrant.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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