Re: Strange problem when upgrading to 7.2 with pg_upgrade. - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Strange problem when upgrading to 7.2 with pg_upgrade.
Date
Msg-id 200202220502.g1M52vK20660@candle.pha.pa.us
Whole thread Raw
In response to Re: Strange problem when upgrading to 7.2 with pg_upgrade.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Strange problem when upgrading to 7.2 with pg_upgrade.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Brian Hirt <bhirt@mobygames.com> writes:
> > I decided to try the pg_upgrade program, something I usually never do.
> 
> > FATAL 2:  read of clog file 0, offset 139264 failed: Success
> 
> Could we see ls -l $PGDATA/pg_clog?
> 
> I suspect that pg_upgrade has neglected to make sure the clog is long
> enough.

Here is the code that sets the transaction id.  Tom, does pg_resetxlog
handle pg_clog file creation properly?# Set this so future backends don't think these tuples are their own# because it
matchestheir own XID.# Commit status already updated by vacuum above# Set to maximum XID just in case SRC wrapped
aroundrecently and# is lower than DST's databaseif [ "$SRC_XID" -gt "$DST_XID" ]then    MAX_XID="$SRC_XID"else
MAX_XID="$DST_XID"fipg_resetxlog-x "$MAX_XID" "$PGDATA"if [ "$?" -ne 0 ]then    echo "Unable to set new XID.  Exiting."
1>&2   exit 1fi
 

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


pgsql-hackers by date:

Previous
From: Marc Munro
Date:
Subject: Re: point in time recovery and moving datafiles online
Next
From: Tom Lane
Date:
Subject: Re: Strange problem when upgrading to 7.2 with pg_upgrade.