Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade relation OID mismatches

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade relation OID mismatches
Date: 2011-11-22 23:29:13
Message-ID: 201111222329.pAMNTDM19052@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Eisentraut wrote:
> On tis, 2011-11-22 at 15:42 -0500, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > I thought these were fixed a while ago, but I'm still seeing these when
> > > upgrading from master to self (using testing script sent in a while
> > > ago).   This is completely reproducible.  What's happening?
> > > 
> > > ...
> > > Restoring user relation files
> > >   /home/peter/devel/postgresql/git/postgresql/contrib/pg_upgra
> > > Mismatch of relation OID in database "regression": old OID 16701, new OID 16689
> > > Failure, exiting
> > 
> > Yes, I certainly thought they were all addressed.  What object is 16701
> > in the old database?  Anything unusual about it?  This is saying the
> > relation oid was not preserved.
> 
> It came in with the range types feature:
> 
> + psql -d regression -x -c 'select * from pg_class where oid = 16701'
> -[ RECORD 1 ]--+----------------
> relname        | test_range_gist
> relnamespace   | 2200
> reltype        | 16703
> reloftype      | 0
> relowner       | 10
> relam          | 0
> relfilenode    | 16701
> reltablespace  | 0
> relpages       | 33
> reltuples      | 6200
> relallvisible  | 33
> reltoastrelid  | 16704
> reltoastidxid  | 0
> relhasindex    | t
> relisshared    | f
> relpersistence | p
> relkind        | r
> relnatts       | 1
> relchecks      | 0
> relhasoids     | f
> relhaspkey     | f
> relhasrules    | f
> relhastriggers | f
> relhassubclass | f
> relfrozenxid   | 1627
> relacl         | 
> reloptions     | 

OK, that is a heap table.  My only guess is that the heap is being
created without binary_upgrade_next_heap_pg_class_oid being set.
Looking at the code, I can't see how the heap could be created without
this happening.  Another idea is that pg_dumpall isn't output the proper
value, but again, how is this data type different from the others.

I will try to research this further.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-11-22 23:38:03
Subject: Permissions checks for range-type support functions
Previous:From: magtiki2@juno.comDate: 2011-11-22 23:19:46
Subject: xpath_table

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group