|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Bruce Momjian <bruce(at)momjian(dot)us>|
|Subject:||Re: ALTER TABLE lock downgrades have broken pg_upgrade|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> I haven't tried to construct a pre-9.1 database that would trigger
> this, but you can make it happen by applying the attached patch
> to create a toast-table-less table in the regression tests,
> and then doing "make check" in src/bin/pg_upgrade. You get this:
> Restoring database schemas in the new cluster
> Creating newly-required TOAST tables SQL command failed
> ALTER TABLE "public"."i_once_had_a_toast_table" RESET (binary_upgrade_dummy_option);
> ERROR: AccessExclusiveLock required to add toast table.
> Failure, exiting
> 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
This implies that there was some totally other patch, probably quite
pg_upgrade-specific, that broke this case independently of the
My conclusion is that we probably do need a specific pg_upgrade support
function to handle the case, rather than trying to sneak it through via
ALTER TABLE, which means that we won't be able to back-patch a fix.
I have no more time to work on this, but I think it needs to be fixed, and
I definitely think we had better put in test coverage when we do fix it.
Attached is a proposed patch that adds regression test coverage for this
and a related case (and triggers the failures I've been complaining of).
regards, tom lane
|Next Message||Stephen Frost||2016-05-06 19:39:57||Re: pgsql: Add TAP tests for pg_dump|
|Previous Message||Robert Haas||2016-05-06 19:31:56||Re: SET ROLE and reserved roles|