Re: pg_upgrade seems a tad broken

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_upgrade seems a tad broken
Дата
Msg-id 201102152346.p1FNkrI04647@momjian.us
обсуждение исходный текст
Ответ на Re: pg_upgrade seems a tad broken  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@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",

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

Предыдущее
От: Jan Urbański
Дата:
Сообщение: Re: pl/python do not delete function arguments
Следующее
От: Tom Lane
Дата:
Сообщение: contrib loose ends: 9.0 to 9.1 incompatibilities