Thread: pg_upgrade seems a tad broken
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.
regards, tom lane
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. + diff --git a/contrib/pg_upgrade/info.c b/contrib/pg_upgrade/info.c index dbbc143..0c518a2 100644 --- a/contrib/pg_upgrade/info.c +++ b/contrib/pg_upgrade/info.c @@ -48,7 +48,7 @@ gen_db_file_maps(DbInfo *old_db, DbInfo *new_db, for (relnum = 0; relnum < old_db->rel_arr.nrels; relnum++) { RelInfo *old_rel = &old_db->rel_arr.rels[relnum]; - RelInfo *new_rel = &old_db->rel_arr.rels[relnum]; + RelInfo *new_rel = &new_db->rel_arr.rels[relnum]; if (old_rel->reloid != new_rel->reloid) pg_log(PG_FATAL, "mismatch of relation id: database \"%s\", old relid %d, new relid %d\n",