From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Paragon Corporation <lr(at)pcorp(dot)us>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7756: When upgrading postgis extension get row is too big: size 9272, maximum size 8160 |
Date: | 2012-12-17 16:25:24 |
Message-ID: | 26090.1355761524@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2012-12-17 10:06:53 -0500, Paragon Corporation wrote:
>> 2012-12-17 09:15:15 EST ERROR: 54000: row is too big: size 9272, maximum
>> size 8160
> Unfortunately that doesn't tell us very much. Could you get a backtrace
> for that? I don't really see which table should receive such large
> tuples...
Hm ... pg_extension does not have a TOAST table. Could the extconfig
and extcondition fields be getting bloated unreasonably? If I
understand the scenario here, this would require (1) the extension
contains a configuration table (probably one with a filter condition)
and (2) for some reason the repeated updates are adding, not replacing,
entries for the table in these columns.
If that's the story it would be easy to verify by watching the
extension's pg_extension entry as you repeatedly upgrade it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Paragon Corporation | 2012-12-17 17:40:30 | Re: BUG #7756: When upgrading postgis extension get row is too big: size 9272, maximum size 8160 |
Previous Message | Paragon Corporation | 2012-12-17 15:19:16 | Re: BUG #7756: When upgrading postgis extension get row is too big: size 9272, maximum size 8160 |