Re: pg_upgrade seems a tad broken

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade seems a tad broken
Дата
Msg-id 28992.1297746263@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_upgrade seems a tad broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_upgrade seems a tad broken  (Bruce Momjian <bruce@momjian.us>)
Re: pg_upgrade seems a tad broken  (Bruce Momjian <bruce@momjian.us>)
Re: pg_upgrade seems a tad broken  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
I wrote:
> I tried to do a pg_upgrade from 9.0.x to HEAD today.  The pg_upgrade run
> went through without complaint, and I could start the postmaster, but
> every connection attempt fails with 

> psql: FATAL:  could not read block 0 in file "base/11964/11683": read only 0 of 8192 bytes

> The database OID varies depending on which database I try to connect to,
> but the filenode doesn't.  In the source 9.0 database, this relfilenode
> belongs to pg_largeobject_metadata.  I'm not sure whether pg_upgrade
> would've preserved relfilenode numbering, so that may or may not be a
> useful hint as to where the problem is.  But in any case it's busted.

Closer investigation shows that in the new database, relfilenode 11683
belongs to pg_class_oid_index, which explains why it's being touched
during backend startup.  It is indeed of zero length, and surely should
not be.  I can't resist the guess that something about the recently
added hacks for pg_largeobject_metadata is not right.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pg_upgrade seems a tad broken
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Change pg_last_xlog_receive_location not to move backwards