Re: Pg_upgrade and toast tables bug discovered

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 <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +