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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Attachment Content-Type Size
unknown_filename text/plain 3.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-01-10 18:09:53 Re: [HACKERS] pg_upgrade
Previous Message Tom Lane 2002-01-10 17:52:30 Re: [HACKERS] pg_upgrade

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-01-10 18:09:53 Re: [HACKERS] pg_upgrade
Previous Message Tom Lane 2002-01-10 17:52:30 Re: [HACKERS] pg_upgrade