Re: Renaming of pg_xlog and pg_clog
От | Bruce Momjian |
---|---|
Тема | Re: Renaming of pg_xlog and pg_clog |
Дата | |
Msg-id | 20161024150627.GB11907@momjian.us обсуждение исходный текст |
Ответ на | Re: Renaming of pg_xlog and pg_clog (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Renaming of pg_xlog and pg_clog
|
Список | 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 по дате отправления: