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. +