Re: BUG #7756: When upgrading postgis extension get row is too big: size 9272, maximum size 8160

I'm beginning to fill a bit dumb.

Attached is a fake_postgis extension that you can just copy the files to
your extension folder that can produce the error if you run the below:

CREATE EXTENSION fake_postgis;
ALTER EXTENSION fake_postgis UPDATE TO "2.1.0next";
ALTER EXTENSION fake_postgis UPDATE TO "2.1.0";
ALTER EXTENSION fake_postgis UPDATE TO "2.1.0next";

I assumed that the :

pg_catalog.pg_extension_config_dump

Calls would overwrite each subsequent for a given object for a given
extension. So I have that in my upgrade script as well should we add more
spatial_ref_sys records we want to avoid dumping.

It seems it just adds.

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Monday, December 17, 2012 12:58 PM
To: Paragon Corporation
Cc: 'Andres Freund'; pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #7756: When upgrading postgis extension get row is
too big: size 9272, maximum size 8160

"Paragon Corporation" <lr(at)pcorp(dot)us> writes:
> The postgis extension has a big custom WHERE condition used to exclude
> the range of spatial_ref_sys records we package postgis from being backed
up.

> pg_extension seems to hold that value in the extcondition column and
> for each upgrade I do adds another array entry. Though that might be
> by design to keep track of previous versions and maybe the designers
> weren't expecting someone crazy enough to stuff in a largish where
> condition :)

For those of us who don't have the latest postgis and all its dependencies
installed, could you extract just the steps of the install and upgrade
scripts that reference this configuration table?

I can see how we might get to this if you were dropping and re-adding the
config table in each cycle, but perhaps that's not what you're doing.

regards, tom lane