[BUGS] BUG #4259: I don't understand this query
The following bug has been logged online: Bug reference: 4259 Logged by: kannan Email address: [EMAIL PROTECTED] PostgreSQL version: 2005 Operating system: Windows 2003 Server Description:I don't understand this query Details: create table [dbo].[olapobjects] ( [id] [varchar] (36) collate sql_latin1_Genenral_Cp1_Ci_As not null, [parent id] [varchar] (36) collate sql_latin1_genenral_cp1_ci_As not null, [objectname] [varchar] (150) collate sql_latin1_genenral_cp1_ci_As not null, [classtype] [int] not null, [object definition] [ntext] collate sql_latin1_genenral_cp1_ci_As null, [lastupdated] [datetime] null, [changed] [bit] nill, [version] [int] null ) on [primary] textimage_on [primary] Go create Table [dbo].[server] ( [objectdefinition] [ntext] collate sql_latin1_genenral_cp1_ci_As null, ) on [primary] textimage_on [primary] -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4259: I don't understand this query
kannan wrote: The following bug has been logged online: Bug reference: 4259 Logged by: kannan Email address: [EMAIL PROTECTED] PostgreSQL version: 2005 There is no version 2005 of PostgreSQL. Additionally, the query syntax you have provided below looks like it'd only be understood by Microsoft SQL Server. I suspect you really meant to contact Microsoft SQL Server support, not file a bug on PostgreSQL. Microsoft people often call Microsoft SQL Server just SQL but in fact SQL is the command language understood by many different database systems, not just MS SQL Server. Description:I don't understand this query That's not really a bug report. What happens when you run the query? What did you expect to happen? If you get error messages, what is the exact text of those error messages? What about the error messages do you not understand? In any case, I suspect you're better off asking this question in an MS SQL Server forum. You might want to think about rewriting it in view of the above questions so that when you do ask it in an appropriate place somebody can understand it well enough to help you. Note: I do not speak for the PostgreSQL team, I'm just a user trying to help out. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Abnormal termination of PostgreSQL
Tom Lane wrote: If you have the time and interest, it might be worth repeating the whole setup sequence starting from initdb. I'm speculating that installing PostGIS might have somehow left corruption in server memory that later manifested as the visible problem. Tom, I'm not sure if I did this right, but a rebuild of that data cluster worked fine. Here's the steps I took (please correct me if I messed something up here): I stopped the server, then just deleted /usr/local/pgsql/data, followed by: # su - postgres $ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data Then I updated pg_hba.conf to the correct access settings, and started the postmaster service again. Following that I logged into psql and set a password for postgres and created a lower-privileged user account (bthoen) to use with the database I will be building (vfm). Then I created the database and spatialized it. $ createdb -O bthoen vfm $ createlang plpgsql vfm $ psql -f /usr/local/pgsql/share/lwpostgis.sql -d vfm Finally I created the corn0715 table and populated it, ran my update script and indexed the table. Finally I did a 'vacuum full' on it to pack it back down. The table seems fine this time, and there was no segfaulting nonsense at any time. But the server log was a lot more active. Whe I loaded this data the first time and had that corruption prroblem, there was hardly anything posted to the log. However, this time I noticed when I ran the postgis script that there was some weirdness written to the log that doesn't look right . Does this look like geos or postgis is a bit broken to you? NOTICE: type histogram2d is not yet defined DETAIL: Creating a shell type definition. NOTICE: return type histogram2d is only a shell NOTICE: argument type histogram2d is only a shell NOTICE: argument type histogram2d is only a shell NOTICE: type spheroid is not yet defined DETAIL: Creating a shell type definition. NOTICE: return type spheroid is only a shell NOTICE: argument type spheroid is only a shell NOTICE: argument type spheroid is only a shell NOTICE: type geometry is not yet defined DETAIL: Creating a shell type definition. NOTICE: return type geometry is only a shell NOTICE: argument type geometry is only a shell NOTICE: argument type geometry is only a shell NOTICE: return type geometry is only a shell NOTICE: return type geometry is only a shell NOTICE: argument type geometry is only a shell NOTICE: argument type geometry is only a shell NOTICE: type box3d is not yet definedDETAIL: Creating a shell type definition. NOTICE: argument type box3d is only a shell NOTICE: return type box3d is only a shell NOTICE: argument type box3d is only a shell NOTICE: type chip is not yet defined DETAIL: Creating a shell type definition. NOTICE: return type chip is only a shell NOTICE: argument type chip is only a shell NOTICE: argument type chip is only a shell NOTICE: type box2d is not yet defined DETAIL: Creating a shell type definition. NOTICE: return type box2d is only a shell NOTICE: argument type box2d is only a shell NOTICE: argument type box2d is only a shell NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index spatial_ref_sys_pkey for table spatial_ref_sys NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index geometry_columns_pk for table geometry_columns ERROR: table corn0715 does not exist STATEMENT: drop table corn0715 ; LOG: checkpoints are occurring too frequently (25 seconds apart) HINT: Consider increasing the configuration parameter checkpoint_segments. LOG: checkpoints are occurring too frequently (25 seconds apart) HINT: Consider increasing the configuration parameter checkpoint_segments. . . . (lots of checkpoints static with the COPY loading, but otherwise things looked normal from here on.) So I think postgres is all right, but I'm not so sure about postgis. I did have problems trying to compile GEOS (and GDAL) so maybe that's where the trouble lies. Any thoughts? - Bill Thoen -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Abnormal termination of PostgreSQL
Bill Thoen [EMAIL PROTECTED] writes: The table seems fine this time, and there was no segfaulting nonsense at any time. But the server log was a lot more active. Whe I loaded this data the first time and had that corruption prroblem, there was hardly anything posted to the log. However, this time I noticed when I ran the postgis script that there was some weirdness written to the log that doesn't look right . Does this look like geos or postgis is a bit broken to you? No, that's more or less the sort of output I'd expect to see from loading the postgis datatypes. There's nothing wrong here that I can tell. So, whatever that glitch was, it seems we don't know how to trigger it. Oh well ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4053: libpq documentation should express clearly, that integers are passed in network octet order
Aleksej Saushev wrote:
The following bug has been logged online:
Bug reference: 4053
Logged by: Aleksej Saushev
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: NetBSD, but this does no matter
Description:libpq documentation should express clearly, that
integers are passed in network octet order
Details:
The documentation on PQexecParams is silent about the precise format,
expected by server for binary parameters, it should be more explicit
and note that integers are expected in network octet order.
I have added this libpq documentation paragraph about how to determine
how to pass binary values. I also added a few comments to the libpq C
code.
Thanks for the report; please let me know if I can improve it more.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/libpq.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.258
diff -c -c -r1.258 libpq.sgml
*** doc/src/sgml/libpq.sgml 1 Jun 2008 16:23:08 - 1.258
--- doc/src/sgml/libpq.sgml 23 Jun 2008 21:09:39 -
***
*** 1397,1402
--- 1397,1410
If the array pointer is null then all parameters are presumed
to be text strings.
/para
+para
+ Values passed in binary format require knowlege of
+ the internal representation expected by the backend.
+ For example, integers must be passed in network byte
+ order. Passing typenumeric/ values requires
+ knowledge of the server storage format, as implemented
+ in filenamesrc/backend/utils/adt/numeric.c/.
+/para
/listitem
/varlistentry
Index: src/interfaces/libpq/fe-exec.c
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.195
diff -c -c -r1.195 fe-exec.c
*** src/interfaces/libpq/fe-exec.c 29 May 2008 22:02:44 - 1.195
--- src/interfaces/libpq/fe-exec.c 23 Jun 2008 21:09:39 -
***
*** 976,987
goto sendFailed;
}
! /* construct the Bind message */
if (pqPutMsgStart('B', false, conn) 0 ||
pqPuts(, conn) 0 ||
pqPuts(stmtName, conn) 0)
goto sendFailed;
if (nParams 0 paramFormats)
{
if (pqPutInt(nParams, 2, conn) 0)
--- 976,988
goto sendFailed;
}
! /* Construct the Bind message */
if (pqPutMsgStart('B', false, conn) 0 ||
pqPuts(, conn) 0 ||
pqPuts(stmtName, conn) 0)
goto sendFailed;
+ /* Send parameter formats */
if (nParams 0 paramFormats)
{
if (pqPutInt(nParams, 2, conn) 0)
***
*** 1001,1006
--- 1002,1008
if (pqPutInt(nParams, 2, conn) 0)
goto sendFailed;
+ /* Send parameters */
for (i = 0; i nParams; i++)
{
if (paramValues paramValues[i])
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
