[BUGS] BUG #6640: pg_dump does not always dump data of tables marked as editable in extension
The following bug has been logged on the website: Bug reference: 6640 Logged by: Regina Obe Email address: l...@pcorp.us PostgreSQL version: 9.1.3 Operating system: Any Description: This seems to be only an issue if a user individually chooses to backup a table marked as editable in an extension, but works fine if full backup is chosen. The particular extension in question here is PostGIS. Please refer to: http://trac.osgeo.org/postgis/ticket/1815 for details. In short -- if I do a full backup of a database, a table marked as editable gets its data backed up as expected, but if I try to backup a schema the table is in or the table itself, pg_dump does not dump anything. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6788: Can't compile on mingw64-w32
The following bug has been logged on the website: Bug reference: 6788 Logged by: Regina Obe Email address: l...@pcorp.us PostgreSQL version: 9.1.4 Operating system: Mingw64-w32 chain Description: I can compile 9.2beta and 9.3 snapshot fine with my mingw64-w32 chain (and can also compile 9.0-9.3 on my mingw64-w64) chain. I'm assuming this issue is fixed in 9.2 and 9.2 and wasn't backported to 9.1 and prior. Perhaps that is intentional. The error I get is a whole bunch of: :\ming32\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.5.4/../../../../i686-w64-min w32/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h n file included from ../../src/include/c.h:90:0 : i686-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaratio n-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I../../src/port -DFRONTEND -I../../src/include - I./src/include/port/win32 -DEXEC_BACKEND "-I../../src/include/port/win32" -c - o getaddrinfo.o getaddrinfo.c In file included from ../../src/include/pg_config_os.h:37:0, from ../../src/include/c.h:90, from getaddrinfo.c:25: c:\ming32\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.5.4/../../../../i686-w64-min gw32/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h In file included from ../../src/include/c.h:90:0 If I look at the offending sections like in src/port/getaddrinfo.c, I see that the section in 9.1 --- 9.1 321-326 #ifdef EAI_NODATA #if !defined(WIN64) && !defined(WIN32_ONLY_COMPILER)/* MSVC/WIN64 duplicate */ case EAI_NODATA: return "No host data of that type was found"; #endif #endif --- end 9.1 -- got changed in 9.2 incarnations -- Thanks, Regina -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7756: When upgrading postgis extension get row is too big: size 9272, maximum size 8160
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 it since I don't know where the error is coming from (what table it's complaining about etc.) and no further detail is given in the logs. I'm the maintainer of the PostGIS extensions so will be happy to change if I'm doing something wrong in packaging. PostGIS to upgrade from 2.+ to 2.1 and any interim revision of 2.1 only has one script which are copied to various versions to support the version naming of extensions since this creates too much junk I have a hack extension script to allow me to upgrade PostGIS 2.1 to any 2.1 super r. Which basically yoyos between 2.1.0 and 2.1.0next and back to 2.1.0 I can upgrade for about 3 times before getting the error and its pretty consistent. 3 times for the postgis one (postgis_topology one I can go on for infinity it seems with the same exercise). I'm pretty sure it's something in our raster machinery tripping it up since if I cut that out, the extension upgrade can be done indefinitely. Of course our raster machinery is the piece that is the most volatile and complicated in structures. I have the bug more described on this ticket: http://trac.osgeo.org/postgis/ticket/1959 I've tried on 9.1 and older 9.2 installs and recently upgrade to 9.2.2 with same issue. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8156: PostGIS crash with immutable functions when immutable function throws an error
The following bug has been logged on the website:
Bug reference: 8156
Logged by: Regina
Email address: l...@pcorp.us
PostgreSQL version: 9.2.4
Operating system: Windows 7 64-bit compiled with visual c++ - EDB 64
Description:
Nothing to do yet unless its obvious to you folks what is wrong here.
I haven't determined if its an issue in how we are compiling PostGIS for
windows or something fundametally wrong in the 9.2 branch on how it handles
windows 64-bit.
Details in this ticket:
http://trac.osgeo.org/postgis/ticket/2185
The issue only seems to exhibit itself in PostgreSQL 9.2.2-9.2.4 (as I
recall 9.2.1 doesn't have this issue).
and it also only happens on windows 7-64bit and windows 2008 64-bit. As far
as I can tell windows 2003 64-bit with same build doesn't have the issue and
as I recall I can't replicate this issue testing under mingw64 either which
we use to compile.
We've only seen it with SQL functions that wrap a PostGIS c function and
that are marked IMMUTABLE STRICT and happens when fed invalid inputs that
would raise an error in the C function. If we take out the IMMUTABLE part
it works fine.
e.g.
This function will crash when used with invalid inputs. such as
ST_AsText('POINT(1 3 hi)')
CREATE OR REPLACE FUNCTION st_astext(text)
RETURNS text AS
' SELECT ST_AsText($1::geometry); '
LANGUAGE sql IMMUTABLE STRICT
COST 100;
This variant the function (note no immutable)
CREATE OR REPLACE FUNCTION st_astextNotImmut(text)
RETURNS text AS
' SELECT ST_AsText($1::geometry); '
LANGUAGE sql STRICT
COST 100;
Makes it not crash.
The 9.3beta1 doesn't have this issue. Nor does the latest 9.1 I have
tested.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8498: pg_trgm is missing from windows edb package
The following bug has been logged on the website: Bug reference: 8498 Logged by: Regina Obe Email address: l...@pcorp.us PostgreSQL version: 9.3.0 Operating system: Windows 2003 x 64-bit Description: I noticed when restoring my 9.2 databases to 9.3 that my pg_trgm extension is missing. In looking it doesn't seem to be packaged with the PostgreSQL 9.3 EDB installer (at least for 64-bit) but I assume it is still a separate extension since it's still in separate modules section http://www.postgresql.org/docs/9.3/static/pgtrgm.html Am I missing something? Sorry if this is an oversight on my part. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
