pg_upgrade seems a tad broken

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

Tom Lane wrote:

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.

OK, I will look at this today. Thanks.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Tom Lane wrote:

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.

FYI, I have reproduced the bug here --- researching the cause now.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Tom Lane wrote:

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.

I have fixed the bug; patch attached and applied. Seems I introduced
it during my pg_upgrade restructuring and didn't run my full regession
test suite after that. My apologies.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +