Re: pg_migrator issues - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_migrator issues
Date
Msg-id 201001041951.o04JpfI27804@momjian.us
Whole thread Raw
In response to Re: pg_migrator issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I was just really asking if disallowing pg_resetxlog -n on a live server
> > is planned behavior or an oversight.  I can see the logic that it should
> > be disallowed but I am just looking for confirmation from someone and I
> > can then drop the issue.
> 
> Well, it's not only a matter of "are we going to clobber live state",
> it's also "is the state that we are looking at changing under us?".
> The -n switch only covers the first point.  I think it would require
> some careful analysis, and testing that's never been done, before having
> any confidence in the results of pg_resetxlog on a live server.

Yea, that was my analysis too.  I will discard the idea and just keep
the pg_migrator code that does either.

> Why should you need this anyway?  pg_migrator should not be having to
> run pg_resetxlog on the old installation, I would think.

Well, the same code is run on the new and old server.  The complex issue
is that the same code that checks for matching controldata settings
(check mode) is the same that pulls the xid from the old server to set
it on the new one.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: quoting psql varible as identifier
Next
From: Bruce Momjian
Date:
Subject: Re: pg_migrator issues