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 →
-
Replace empty locale name with implied value in CREATE DATABASE and initdb.
- c7cea267de3c 9.2.0 cited