On Thu, Sep 4, 2014 at 01:14:01PM -0600, Noah Yetter wrote:
> Isn't that exactly what the release note says?
> "where the new server creates a TOAST table but the old version did not"
> vs.
> "where the new cluster needs a TOAST table that the old cluster didn't"
Sorry, yes, I got confused. We have always handled cases where the old
cluster needed a TOAST table and the new cluster didn't. The 9.3.5 fix
is to prevent a certain failure for a new-only TOAST table:
commit 3088cc37044a303fc50857d8d9e7e44b5c250642
Author: Bruce Momjian <br...@momjian.us>
Date: Mon Jul 7 13:24:08 2014 -0400
pg_upgrade: allow upgrades for new-only TOAST tables
Previously, when calculations on the need for toast tables changed,
pg_upgrade could not handle cases where the new cluster needed a
TOAST
table and the old cluster did not. (It already handled the opposite
case.) This fixes the "OID mismatch" error typically generated in
this
case.
Backpatch through 9.2
The post-9.3.5 fix is for OID conflict that _can_ happen from a new-only
TOAST tables:
commit 4c6780fd17aa43ed6362aa682499cc2f9712cc8b
Author: Bruce Momjian <br...@momjian.us>
Date: Thu Aug 7 14:56:13 2014 -0400
pg_upgrade: prevent oid conflicts with new-cluster TOAST tables
Previously, TOAST tables only required in the new cluster could
cause
oid conflicts if they were auto-numbered and a later conflicting
oid had
to be assigned.
Backpatch through 9.3
> At any rate, I've additionally observed that the relation which is blowing up
> pg_upgrade is a VIEW in the source cluster but gets created as a TABLE in the
> upgraded cluster, which may better explain why it had no toast table before
> and
> now it does. Is this some kind of expected behavior for views?
Uh, it certainly should not be creating a table instead of a view,
though it will get a pg_class entry.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
