Re: [BUGS] Installing to Windows XP cannot create db
[EMAIL PROTECTED] wrote: Hi, I have managed to install the service on my windows XP box, but when I try to create a database I get: Creating database 'test' . . . E_LQ0001 Failed to connect to DBMS session. E_LC0001 GCA protocol service (GCA_REQUEST) failure. Internal service status E_GC0135 -- A default server class has been defined (by II_GCN_SVR_TYPE), but that server class is not known to the Name Server.. Are you sure that's a PostgreSQL error, and not from something else (e.g. Ingres?) -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #1865: isinf wrongly dectected under Solaris 9
The following bug has been logged online: Bug reference: 1865 Logged by: Bob Friesenhahn Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.8 Operating system: Solaris 9 (SPARC) Description:isinf wrongly dectected under Solaris 9 Details: Using GCC 4.0.1 on Solaris 9 the configure test for isinf incorrectly detects success so postgres does not link. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #1864: Strange behavoir of batches
The following bug has been logged online: Bug reference: 1864 Logged by: Angelo Neuschitzer Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.7 Operating system: Debian Linux (+ Win 2k) Description:Strange behavoir of batches Details: Good greetings, I had a strange behaiviour while I was working with the postgres, I have to admit that I used it wrong in the first place but the 'trouble' was still there, you don't have to fix this (cause it does not happen in 'common' behaivour) but you should know. some more information you might want to have: Programming Language: Java (jdk 1.5.0_04) postgres driver: pg74.216.jdbc3.jar Postgres lives on Debian Linux, Server on Win 2k I used Batches to write some Information into the db. for I understood the ussage of addBatch false I called it everytime, but the last one. In my Program there were 3 blocks of inserting done in a row. 5 blocks of insterting per call. first block insterted 93 rows (in table A) second instered 82 rows (in table B) third 2 (in table C) fourth 9 (in table D) [whereas Tables B,C and D have a reference on Table A] fith entered a reference to all 93 rows of (table A) in table (E). in the fith block at row 82 the batch failed because It did not match the foreign key constraint of table A TO table D In the debugging process I changed the order of inserting and it worked (means I inserted into A, C, D, B and then the 93 references in Table E). this way it worked out, I got no trouble and everything was where it belonged to. (now I'm calling addBatch in every row and it works in every order) If this was not understandable or you want to have some more information (or some sample code) don't hestiate to mail me, but as I have lots of work It may take a day or two till I anser. Please notice that I may not give you the original code or database structure cause my company does not develop this project open source. (and please forgive my bad english) Zo Phar Angelo Neuschitzer ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1866: -lreadline needs -lcurses under Solaris.
The following bug has been logged online: Bug reference: 1866 Logged by: Bob Friesenhahn Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4.8 Operating system: Solaris 9 (SPARC) Description:-lreadline needs -lcurses under Solaris. Details: The Postgres configure script finds the readline 5.0 headers and decides that readline is available (in spite of many individual errors while testing for functions in config.log). The end result is that postgres is built as if readline is available but neither -lreadline or -lcurses is applied when linking psql so it fails to link. Manually adding -lreadline -lcurses while linking pgsql results in a successful link, possibly with reduced functionality. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1864: Strange behavoir of batches
Angelo Neuschitzer wrote:
The following bug has been logged online:
Bug reference: 1864
Logged by: Angelo Neuschitzer
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.7
Operating system: Debian Linux (+ Win 2k)
Description:Strange behavoir of batches
Details:
Good greetings,
I had a strange behaiviour while I was working with the postgres, I have to
admit that I used it wrong in the first place but the 'trouble' was still
there, you don't have to fix this (cause it does not happen in 'common'
behaivour) but you should know.
some more information you might want to have:
Programming Language: Java (jdk 1.5.0_04)
postgres driver: pg74.216.jdbc3.jar
Postgres lives on Debian Linux, Server on Win 2k
I used Batches to write some Information into the db.
for I understood the ussage of addBatch false I called it everytime, but the
last one.
OK - this seems to be a Java thing, yes? stmt.addBatch()
In my Program there were 3 blocks of inserting done in a row. 5 blocks of
insterting per call.
first block insterted 93 rows (in table A)
second instered 82 rows (in table B)
third 2 (in table C)
fourth 9 (in table D)
[whereas Tables B,C and D have a reference on Table A]
fith entered a reference to all 93 rows of (table A) in table (E).
in the fith block at row 82 the batch failed because It did not match the
foreign key constraint of table A TO table D
And was this correct or not? Did row 82 reference a valid row in table A
or not?
In the debugging process I changed the order of inserting and it worked
(means I inserted into A, C, D, B and then the 93 references in Table E).
this way it worked out, I got no trouble and everything was where it
belonged to.
(now I'm calling addBatch in every row and it works in every order)
Not sure what you mean by this.
My understanding is that you do something like:
stmt.addBatch('INSERT INTO ... VALUES (1,...)');
stmt.addBatch('INSERT INTO ... VALUES (2,...)');
stmt.addBatch('INSERT INTO ... VALUES (3,...)');
stmt.addBatch('INSERT INTO ... VALUES (4,...)');
resultCodes = stmt.executeBatch();
Which should execute four insert statements.
If this was not understandable or you want to have some more information (or
some sample code) don't hestiate to mail me, but as I have lots of work It
may take a day or two till I anser.
Please notice that I may not give you the original code or database
structure cause my company does not develop this project open source.
If this is a bug, it sounds like it is in the JDBC driver. In which
case, you should probably talk to them (http://jdbc.postgresql.org/),
but they'll probably need a short example of how to reproduce it.
(and please forgive my bad english)
Your English is fine sir.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1863: Install won't work
Howard Brodale wrote: The following bug has been logged online: Bug reference: 1863 Logged by: Howard Brodale Email address: [EMAIL PROTECTED] PostgreSQL version: 8.03 Operating system: Win 98 2nd ed Description:Install won't work I don't believe win Me/98/95/3.1 are supported for PostgreSQL. Windows 2000 and on should be fine though. If you really need to run PG on Win98, perhaps take a look at the cygwin project and see about installing via that route. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1866: -lreadline needs -lcurses under Solaris.
Bob Friesenhahn wrote: > The Postgres configure script finds the readline 5.0 headers and > decides that readline is available (in spite of many individual > errors while testing for functions in config.log). The end result is > that postgres is built as if readline is available but neither > -lreadline or -lcurses is applied when linking psql so it fails to > link. Manually adding -lreadline -lcurses while linking pgsql results > in a successful link, possibly with reduced functionality. Again, please provide config.log and the build log for analysis. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1865: isinf wrongly dectected under Solaris 9
Bob Friesenhahn wrote: > Using GCC 4.0.1 on Solaris 9 the configure test for isinf incorrectly > detects success so postgres does not link. Please provide the config.log file and the tail end of the failing build log (at least the failing command and the error message). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] ia64-hp-hpux11.23 configure warnings
checking build system type... ia64-hp-hpux11.23 checking host system type... ia64-hp-hpux11.23 ... checking sys/ipc.h presence... yes configure: WARNING: sys/ipc.h: present but cannot be compiled configure: WARNING: sys/ipc.h: check for missing prerequisite headers? configure: WARNING: sys/ipc.h: see the Autoconf documentation configure: WARNING: sys/ipc.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/ipc.h: proceeding with the preprocessor's result configure: WARNING: sys/ipc.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## There are several more of these sorts of warnings in the attached complete configure output. Thanks, Ed checking build system type... ia64-hp-hpux11.23 checking host system type... ia64-hp-hpux11.23 checking which template to use... hpux checking whether to build with 64-bit integer date/time support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking if gcc supports -Wdeclaration-after-statement... no checking if gcc supports -Wold-style-definition... no checking if gcc supports -Wendif-labels... yes checking if gcc supports -fno-strict-aliasing... yes configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing checking whether the C compiler still works... yes checking how to run the C preprocessor... gcc -E checking allow thread-safe client libraries... no checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with Bonjour support... no checking whether to build with OpenSSL support... no checking for egrep... grep -E configure: using CPPFLAGS=-D_XOPEN_SOURCE_EXTENDED configure: using LDFLAGS= checking for gawk... gawk checking for flex... /usr/local/bin/flex checking whether ln -s works... yes checking for ld used by GCC... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for ranlib... ranlib checking for lorder... lorder checking for tar... /usr/bin/tar checking for strip... strip checking whether it is possible to strip libraries... no checking for bison... bison -y checking for perl... /usr/local/bin/perl checking for main in -lbsd... no checking for setproctitle in -lutil... no checking for main in -lm... yes checking for main in -ldl... yes checking for main in -lnsl... yes checking for main in -lsocket... no checking for main in -lipc... no checking for main in -lIPC... no checking for main in -llc... no checking for main in -ldld... yes checking for main in -lld... no checking for main in -lcompat... no checking for main in -lBSD... no checking for main in -lgen... yes checking for main in -lPW... no checking for main in -lresolv... no checking for library containing getopt_long... no checking for main in -lunix... no checking for library containing crypt... none required checking for library containing fdatasync... none required checking for shmget in -lcygipc... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking crypt.h usability... yes checking crypt.h presence... yes checking for crypt.h... yes checking dld.h usability... no checking dld.h presence... no checking for dld.h... no checking endian.h usability... no checking endian.h presence... no checking for endian.h... no checking fp_class.h usability... no checking fp_class.h presence... no checking for fp_class.h... no checking getopt.h usability... no checking getopt.h presence... no checking for getopt.h... no checking ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/ipc.h usability... no checking sys/ipc.h presence... yes configure: WARNING: sys/ipc.h: prese
Re: [BUGS] ia64-hp-hpux11.23 configure warnings
On Thursday September 8 2005 12:20 pm, Ed L. wrote: > checking build system type... ia64-hp-hpux11.23 > checking host system type... ia64-hp-hpux11.23 > ... > checking sys/ipc.h presence... yes > configure: WARNING: sys/ipc.h: present but cannot be compiled > configure: WARNING: sys/ipc.h: check for missing > prerequisite headers? configure: WARNING: sys/ipc.h: see the > Autoconf documentation configure: WARNING: sys/ipc.h: > section "Present But Cannot Be Compiled" configure: WARNING: > sys/ipc.h: proceeding with the preprocessor's result > configure: WARNING: sys/ipc.h: in the future, the compiler > will take precedence configure: WARNING: ## > ## configure: > WARNING: ## Report this to pgsql-bugs@postgresql.org ## > configure: WARNING: ## > ## > Build failure of 8.1beta1 for ia64-hp-hpux11.23: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -I../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o pg_sema.o pg_sema.c In file included from pg_sema.c:22: /usr/include/sys/ipc.h:51: error: parse error before "cid_t" /usr/include/sys/ipc.h:56: error: parse error before '}' token In file included from pg_sema.c:25: /usr/include/sys/sem.h:91: error: field `sem_perm' has incomplete type gmake[3]: *** [pg_sema.o] Error 1 gmake[3]: Leaving directory `/users/dists/pgsql/builds/postgresql-8.1beta1/src/backend/port' gmake[2]: *** [port-recursive] Error 2 gmake[2]: Leaving directory `/users/dists/pgsql/builds/postgresql-8.1beta1/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/users/dists/pgsql/builds/postgresql-8.1beta1/src' gmake: *** [all] Error 2 *** Error exit code 2 Ed ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] ia64-hp-hpux11.23 configure warnings
Ed L. wrote: > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels > -fno-strict-aliasing -I../../../src/include -D_XOPEN_SOURCE_EXTENDED > -c -o pg_sema.o pg_sema.c In file included from pg_sema.c:22: > /usr/include/sys/ipc.h:51: error: parse error before "cid_t" > /usr/include/sys/ipc.h:56: error: parse error before '}' token Evidently, you need to include another header before sys/ipc.h, namely the one that defines the cid_t type. Care to find out which one that is? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #1865: isinf wrongly dectected under Solaris 9
Bob Friesenhahn wrote: > The config.log and a build log are attached. It's puzzling why the test program compiles and links without complaint when the isinf() function does not exist. Can you try to isolate the test program from configure and see what is going on? > Note that there are > actually two bugs in the build but the build terminates due to the > isinf bug. The failure to link due to -lreadline needing -lcurses > does not occur until later. In the logs you sent, configure decides to use -ledit, which is something different altogether. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] ia64-hp-hpux11.23 configure warnings
"Ed L." <[EMAIL PROTECTED]> writes: > In file included from pg_sema.c:22: > /usr/include/sys/ipc.h:51: error: parse error before "cid_t" > /usr/include/sys/ipc.h:56: error: parse error before '}' token So where is cid_t defined? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] ia64-hp-hpux11.23 configure warnings
On Thursday September 8 2005 2:18 pm, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> writes: > > In file included from pg_sema.c:22: > > /usr/include/sys/ipc.h:51: error: parse error before "cid_t" > > /usr/include/sys/ipc.h:56: error: parse error before '}' > > token > > So where is cid_t defined? /usr/include/sys/types.h: typedef int32_t cid_t; /* For compartment IDs */ This is 8.1beta1. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] ia64-hp-hpux11.23 configure warnings
On Thursday September 8 2005 3:48 pm, Ed L. wrote: > On Thursday September 8 2005 2:18 pm, Tom Lane wrote: > > "Ed L." <[EMAIL PROTECTED]> writes: > > > In file included from pg_sema.c:22: > > > /usr/include/sys/ipc.h:51: error: parse error before > > > "cid_t" /usr/include/sys/ipc.h:56: error: parse error > > > before '}' token > > > > So where is cid_t defined? > > /usr/include/sys/types.h: typedef int32_t cid_t; > /* For compartment IDs */ > > This is 8.1beta1. I see sys/ipc.h already #includes sys/types.h, though. Ed ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] ia64-hp-hpux11.23 configure warnings
"Ed L." <[EMAIL PROTECTED]> writes: > I see sys/ipc.h already #includes sys/types.h, though. Possibly there's some magic #define needed to expose the cid_t definition? We have this in src/template/hpux CPPFLAGS="-D_XOPEN_SOURCE_EXTENDED" because it seems necessary on HPUX 10. It used to work on HPUX 11 too, the last time I tried that ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1862: ECPG Connect, host variable trailing blanks
On Wed, Sep 07, 2005 at 12:06:10PM -0700, [EMAIL PROTECTED] wrote: > According to the documentation at: > http://www.postgresql.org/docs/8.0/static/ecpg-connect.html > >EXEC SQL CONNECT TO :target USER :user; >The last form makes use of the variant referred to above as character >variable reference. The complete text is: The last form makes use of the variant referred to above as character variable reference. You will see in later sections how C variables can be used in SQL statements when you prefix them with a colon. Note "C variables" -- it's talking about the C character type, not the SQL character type. > To be consistent with other uses of host variables, > we request that host variables within a connect statement > act like host variables in DML statements. They *do* act the same way: the value is passed to the server, which handles it according to the appropriate type's semantics. If the host variable's value is used in a CHAR context then trailing spaces aren't significant in comparisons; if the value is used in other contexts like VARCHAR, TEXT, or NAME, then trailing spaces *are* significant. The server makes the decision, not the ECPG preprocessor or library, which simply passes the value to the server. If you think this behavior should be changed then propose it on pgsql-hackers and discuss it with the developers. -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1862: ECPG Connect, host variable trailing blanks
Michael Fuhr <[EMAIL PROTECTED]> writes: > If you think this behavior should be changed then propose it on > pgsql-hackers and discuss it with the developers. I doubt we'll consider changing it. If I haven't missed any of the details, the critical points here are (1) User names containing trailing (or embedded) spaces are legal. Not a very good idea maybe, but legal both per SQL spec and per our historical practice. (2) Making ECPG strip trailing spaces would render it unable to connect as such a user. I don't think ECPG has any business deciding that trailing spaces are insignificant. If that's the case in your application environment, fine: strip the spaces at the application level. But don't expect a general-purpose library to make that policy choice for you. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
