The following bug has been logged on the website:
Bug reference: 7756
Logged by: Regina Obe
Email address: l...@pcorp.us
PostgreSQL version: 9.2.2
Operating system: Windows 64-bit, Window 32-bit
Description:
This might be a postgis issue, but I don't know how to debug
Hi,
On 2012-12-17 13:56:13 +, l...@pcorp.us wrote:
> row is too big: size 9280, maximum size 8160
If you enable more verbose error output I think you should get a bit
more context, including the table name on which this happens, that might
already help quite a bit. Or do you have that alread
Andres,
Sorry not sure why I didn't think of that.
The more descriptive error it gives in logs is:
2012-12-17 09:15:10 EST LOG: statement:
SET log_error_verbosity = 'verbose';
2012-12-17 09:15:13 EST LOG: 0: statement: ALTER EXTENSION postgis
UPDATE TO "2.1.0SVN";
2012-12
Hi,
On 2012-12-17 10:06:53 -0500, Paragon Corporation wrote:
> Andres,
> Sorry not sure why I didn't think of that.
>
> The more descriptive error it gives in logs is:
>
> 2012-12-17 09:15:10 EST LOG: statement:
> SET log_error_verbosity = 'verbose';
> 2012-12-17 09:15:13 EST LOG: 0: s
I'll try to do that later. This is on my EDB install on server with no dev
tools.
As I recall I think my mingw64 exhibits same issue so I'll do a gdb against
both my edb and mingw using the mingw gdb. Can't get to that until later
unfortunately.
Thanks,
Regina
-Original Message-
From:
Andres Freund 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 re
Tom,
I think you may have found the problem.
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 anot
"Paragon Corporation" 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
On 2012-12-17 12:40:30 -0500, Paragon Corporation wrote:
> I couldn't get my EDB install to give anything meaningful to back trace, but
> same issue happens on my mingw dev install (which is running 9.2.1)
> I have the backtrace for that on this ticket:
>
> http://trac.osgeo.org/postgis/ticket/1959
On Sun, 2012-12-16 at 21:17 -0500, Tom Lane wrote:
> I wrote:
> > On the whole I think resurrecting the rd_islocaltemp flag might be the
> > best thing. We can keep the use of "relpersistence ==
> > RELPERSISTENCE_TEMP" to do what rd_istemp used to do, it's just the
> > equation of "rd_backend ==
Jeff Davis writes:
> On Sun, 2012-12-16 at 21:17 -0500, Tom Lane wrote:
>> One thing I noticed that maybe needs more work is that tablecmds.c in
>> general seems mighty willing to hack upon temp tables belonging to other
>> sessions. I added tests for that in the places where there already were
>
"Paragon Corporation" writes:
> 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:
Great, thanks for the test case.
> I assumed that the :
> pg_catalog.pg_extension_config_dump
> Calls would overwrite
The following bug has been logged on the website:
Bug reference: 7757
Logged by: clayton stanley
Email address: cstan...@cstanley.no-ip.biz
PostgreSQL version: 9.2.2
Operating system: os x 10.6.8
Description:
see this SO post:
http://stackoverflow.com/questions/13905
13 matches
Mail list logo
