On Fri, May 6, 2016 at 03:32:23PM -0400, Tom Lane wrote: > > I think possibly the easiest fix for this is to have pg_upgrade, > > instead of RESETting a nonexistent option, RESET something that's > > still considered to require AccessExclusiveLock. "user_catalog_table" > > would work, looks like; though I'd want to annotate its entry in > > reloptions.c to warn people away from downgrading its lock level. > > I tried fixing it like that. The alternate RESET target had behaved as > expected when I'd tested by hand, but in pg_upgrade it still fails, > only now with > > Creating newly-required TOAST tables SQL command failed > ALTER TABLE "public"."i_need_a_toast_table" RESET (user_catalog_table); > ERROR: pg_type OID value not set when in binary upgrade mode
I think this means that the ALTER TABLE RESET is adding or potentially adding a pg_type row, and no one called binary_upgrade_set_next_pg_type_oid(). -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
