Re: ALTER TABLE lock downgrades have broken pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TABLE lock downgrades have broken pg_upgrade
Date
Msg-id 19748.1462298316@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TABLE lock downgrades have broken pg_upgrade  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2016-05-03 12:07:51 -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.

> Alternatively we could just add a function for adding a toast table -
> that seems less hacky and less likely to be broken in the future.

We used to have an explicit "ALTER TABLE CREATE TOAST TABLE", IIRC,
but we got rid of it.  In any case, forcible creation is not what
we're after here, we just want to create it if needs_toast_table()
thinks we need one.  I'm fine with it being a hack, as long as we
have test coverage so we notice when somebody breaks the hack.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER TABLE lock downgrades have broken pg_upgrade
Next
From: Robert Haas
Date:
Subject: Re: pg_upgrade and toasted pg_largeobject