Lists: | pgsql-hackers |
---|
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | pg_upgrade seems a tad broken |
Date: | 2011-02-15 04:53:40 |
Message-ID: | 28764.1297745620@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: pg_upgrade seems a tad broken |
Date: | 2011-02-15 05:04:23 |
Message-ID: | 28992.1297746263@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | 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
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: pg_upgrade seems a tad broken |
Date: | 2011-02-15 14:25:39 |
Message-ID: | 201102151425.p1FEPdM27061@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: pg_upgrade seems a tad broken |
Date: | 2011-02-15 15:23:27 |
Message-ID: | 201102151523.p1FFNRN08398@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: pg_upgrade seems a tad broken |
Date: | 2011-02-15 23:46:53 |
Message-ID: | 201102152346.p1FNkrI04647@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment | Content-Type | Size |
---|---|---|
/rtmp/diff | text/x-diff | 601 bytes |