Horton

Thread

  1. pg_upgrade seems a tad broken

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-02-15T04:53:40Z

    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

  2. Re: pg_upgrade seems a tad broken

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-02-15T05:04:23Z

    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

  3. Re: pg_upgrade seems a tad broken

    Bruce Momjian <bruce@momjian.us> — 2011-02-15T14:25:39Z

    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. +

  4. Re: pg_upgrade seems a tad broken

    Bruce Momjian <bruce@momjian.us> — 2011-02-15T15:23:27Z

    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. +

  5. Re: pg_upgrade seems a tad broken

    Bruce Momjian <bruce@momjian.us> — 2011-02-15T23:46:53Z

    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. +