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 3088cc37044a303fc50857d8d9e7e44b5c250642Author: Bruce Momjian <bruce@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
tableschanged, pg_upgrade could not handle cases where the new cluster needed a TOAST table and the old cluster
didnot. (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 4c6780fd17aa43ed6362aa682499cc2f9712cc8bAuthor: Bruce Momjian <bruce@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
thenew 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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +