Re: Renaming of pg_xlog and pg_clog - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Renaming of pg_xlog and pg_clog
Date
Msg-id 20161024150627.GB11907@momjian.us
Whole thread Raw
In response to Re: Renaming of pg_xlog and pg_clog  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Renaming of pg_xlog and pg_clog  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, Oct 24, 2016 at 11:59:42AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote:
> 
> > > I think the apt-get behaviour was specifically designed to ensure it
> > > couldn't easily be put into a script which I would have said was
> > > desirable -- except I suspect there are situations where Postgres
> > > database scripts need to do a resetxlog. I'm not sure I can think of
> > > any examples offhand but I wouldn't be too surprised.
> > 
> > Yes, pg_upgrade has eight calls to pg_resetxlog to set various value.
> 
> There is one difference though, which is that the really destructive
> use of pg_resetxlog is the one that removes pg_xlog files.  The other
> uses that simply set flags in the control file are not as bad -- you can
> simply go back to what the original value was.  I think we would only
> need the obnoxious string requirement in the most dangerous mode.
> 
> Alternatively, we could separate the tool in two different executables.

OK, but we are going need to document that this special flag is only
needed for certain option uses.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Renaming of pg_xlog and pg_clog
Next
From: Petr Jelinek
Date:
Subject: Re: [PATCH] Send catalog_xmin separately in hot standby feedback