Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Rural Hunter <ruralhunter@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2012-09-19T06:05:38Z
Lists: pgsql-hackers
On Tue, Sep 18, 2012 at 07:22:39PM -0400, Bruce Momjian wrote:
> > Based on the fact that sql_features exists in the information_schema
> > schema, I don't think 'sql_features' table is actually being processed
> > by pg_upgrade, but I think its TOAST table, because it has a high oid,
> > is being processed because it is in the pg_toast schema.  This is
> > causing the mismatch between the old and new clusters.
> > 
> > I am thinking this query needs to be split apart into a UNION where the
> > second part handles TOAST tables and looks at the schema of the _owner_
> > of the TOAST table.  Needs to be backpatched too.
> 
> OK, I am at a conference now so will not be able to write-up a patch
> until perhaps next week.  You can drop the information schema in the old
> database and pg_upgrade should run fine.  I will test your failure once
> I create a patch.

One good thing is that pg_upgrade detected there was a bug in the code
and threw an error, rather than producing an inaccurate dump.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Replace empty locale name with implied value in CREATE DATABASE and initdb.