Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] pg_upgrade

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] pg_upgrade
Date: 2002-01-10 18:08:00
Message-ID: 200201101808.g0AI80h29105@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Here is a patch I need to /contrib/pg_resetxlog to support a new "-x
> > XID" option to set the XID in pg_control.
> 
> I don't like this patch.  It seems weird to add -x as an independent
> function rather than just have pg_resetxlog do its normal thing and
> allow -x to override the xid value.  -x defined that way makes sense
> in the context of pg_resetxlog's original mission (in particular, one
> should be able to use it in the situation where the old pg_control is
> unrecoverable).  Also, there's no good reason for pg_upgrade not to
> reset the xlog --- certainly we would not want the records therein to
> be replayed against the pg_upgraded database!

OK, if we want to reset WAL at the same time, which does make sense as
you say, here is the patch.  This is even easier for me.   It just
optionally sets the XID as part of the normal operation.  (I am going to
commit this patch because it is better for you and smaller than the one
I just committed from last night.)

> There is a more serious problem, also.  Pages transferred over from the
> old database will contain LSN values pointing into the old xlog.  If
> these are past the end of the new database's xlog (very probable) then
> you have a strong risk of "XLogFlush: request past end of xlog" errors,
> which per Vadim's insistence we treat as a system-wide fatal condition.
> 
> Probably the cleanest way to deal with that is to tweak pg_resetxlog
> further to have an optional switch with a minimum xlog position.
> It already knows how to set up its cleared xlog with a position >=
> end of the removed log, so you could have an additional option switch
> that forces the new position to be >= switch value.  To issue the
> switch, pg_upgrade would have to look at the old xlog files to determine
> the endpoint of the old xlog.  Seems messy but not impossible.

Wow, that sounds hard.  Can you give me some hints which pg_control
field that is in?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-01-10 18:09:53
Subject: Re: [HACKERS] pg_upgrade
Previous:From: Tom LaneDate: 2002-01-10 17:52:30
Subject: Re: [HACKERS] pg_upgrade

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-01-10 18:09:53
Subject: Re: [HACKERS] pg_upgrade
Previous:From: Tom LaneDate: 2002-01-10 17:52:30
Subject: Re: [HACKERS] pg_upgrade

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group