On Wed, Jun 8, 2016 at 10:41 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> catversion is not relevant to GUC changes. It's not really necessary, >>> because you'd get a clean, easily diagnosed and repaired failure during >>> postmaster startup anyway. The point of bumping catversion is to prevent >>> a postmaster starting when the incompatibility is subtler or harder to >>> debug than that. > >> The reloption is also getting renamed here. > > Hmm. I forget what the behavior is if we see an unrecognized reloption > already stored in the catalogs, but it might be worth checking. If > that's something that's painful to get out of, maybe a catversion bump > would be appropriate.
rhaas=# create table tgl (a int); CREATE TABLE rhaas=# alter table tgl set (parallel_degree = 3); ALTER TABLE rhaas=# select reloptions from pg_class where relname = 'tgl'; reloptions --------------------- {parallel_degree=3} (1 row) rhaas=# update pg_class set reloptions = '{beats_me=3}' where relname = 'tgl'; UPDATE 1 rhaas=# alter table tgl reset (beats_me); ALTER TABLE rhaas=# select reloptions from pg_class where relname = 'tgl'; reloptions ------------ (1 row) So it's not hard to get rid of. pg_dump does dump the unrecognized option, which will fail at restore time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers