Re: Strange problem when upgrading to 7.2 with pg_upgrade.
От | Bruce Momjian |
---|---|
Тема | Re: Strange problem when upgrading to 7.2 with pg_upgrade. |
Дата | |
Msg-id | 200202220502.g1M52vK20660@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Strange problem when upgrading to 7.2 with pg_upgrade. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Strange problem when upgrading to 7.2 with pg_upgrade.
|
Список | 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 по дате отправления: