Re: [BUGS] Autocomit off in psql don't work
Tom Lane wrote: > Olleg <[EMAIL PROTECTED]> writes: > > olleg=# \set AUTOCOMMIT OFF > > It has to be > > \set AUTOCOMMIT off > > Not sure if we should be more flexible about this or not. The code says > > /* >* for backwards compatibility, anything except "off" is taken as >* "true" >*/ That seems pretty strange to me. Is this a TODO? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Conflicts with autoconf macroses
Peter Eisentraut wrote: Tom Lane writes: Olleg <[EMAIL PROTECTED]> writes: It's bug, autoconf headers may not be included in "library headers". If you think it's a bug you'd better complain to the autoconf people. pg_config.h is generated entirely by autoconf tools. Admittedly, you're not supposed to install the generated config.h files, I am working on a server module. I need postgresql.h. pg_config.h is included in postgresql.h because of this kind of name conflict. There is a contributed macro that automatically prefixes all macro names so they don't conflict. May be worth checking out. ??? Please explain. -- Olleg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Wierd MD5-authentication crash on Solaris 8
Severity: Core dump Frequency: Unusual PostgreSQL Version: 7.4.0 release Platform: Solaris 8 gmake 3.80 gcc 3.23 440mhz UltraSparc III Netra T1/105 Reproducability: 100% on this machine and an identical one. Not yet tested on other machines running Solaris 8. Summary: attempting to connect via MD5 authentication as a user who has no password triggers a core dump of Postmaster. Steps to Reproduce: 1) set localhost authentication to MD5 2) set up a new user without setting a password. 3) attempt to connect as that user. Core dump file is available.Strace can also be done if desired. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] Corrupted string length for bit(n) in information schema
Your name : Claus Colloseus
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture : AMD Athlon XP 2000+
Operating System : Windows 2000 V. 5.00.2195
PostgreSQL version: PostgreSQL-7.4
Compiler used : precompiled for Cygwin distribution:
postgresql-7.4-1.tar.bz2 from 23.11.2003
Please enter a FULL description of your problem:
After creating a domain of type bit(n), the length n is given back
with another number from the information schema. The same distended
number shows up f. e. in the SQL script or the Property table
of pgAdmin.
In the tested case, instead of n=10 as input, n=6 was given back.
Furthermore, a check constraint for the domain doesn't show up in
the information_schema.check_constraints table at all.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
A test Database was created by pgAdmin III Version 1.0.1 (Oct 14 2003)
for Windows with:
CREATE DATABASE test
WITH ENCODING = 'UNICODE';
The following was executed with psql V. 7.4 in a Cygwin Bash shell:
CREATE DOMAIN public.dom_10bit
AS bit(10)
DEFAULT B'00'
NOT NULL
CHECK ((VALUE = B'00') OR (VALUE = B'01'));
Afterwards, the following queries gave the respective results:
SELECT domain_name, data_type, character_maximum_length, character_octet_length,
domain_default, udt_name, dtd_identifier
FROM information_schema.domains
WHERE domain_name = 'dom_10bit';
domain_name | data_type | character_maximum_length | character_octet_length |
domain_default| udt_name | dtd_identifier
-+---+--++--+--+
dom_10bit | bit |6 ||
B'00'::"bit" | bit | 1
(1 row)
SELECT *
FROM information_schema.check_constraints;
constraint_catalog | constraint_schema | constraint_name | check_clause
+---+-+--
(0 rows)
SELECT typname, typlen, typtype, typtypmod, typdefaultbin
FROM pg_type
WHERE typname = 'dom_10bit';
typname | typlen | typtype | typtypmod |
typdefaultbin
---++-+---+--
dom_10bit | -1 | d |10 | {FUNCEXPR :funcid 1685 :funcresulttype
1560 :funcretset false :funcformat 2 :args ({CONST :consttype 1560 :constlen -1
:constbyval false :constisnull false :constvalue 10 [ 10 0 0 0 10 0 0 0 0 0 ]} {CONST
:consttype 23 :constlen 4 :constbyval true :constisnull false :constvalue 4 [ 10 0 0 0
]} {CONST :consttype 16 :constlen 1 :constbyval true :constisnull false :constvalue 1
[ 0 0 0 0 ]})}
(1 row)
SELECT conname, contype, conbin, consrc
FROM pg_type t INNER JOIN pg_constraint c
ON t.oid = c.contypid
WHERE typname = 'dom_10bit';
conname | contype |
conbin
| consrc
-+-+--+
$1 | c | {BOOLEXPR :boolop or :args ({OPEXPR :opno 1784 :opfuncid 0
:opresulttype 16 :opretset false :args ({COERCETODOMAINVALUE :typeId 1560
[BUGS] libpq3 + ssl memory leak
POSTGRESQL BUG REPORT TEMPLATE
Your name : Olaf Hartmann
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : i386
Operating System (example: Linux 2.0.26 ELF) : linux-2.4.21
PostgreSQL version (example: PostgreSQL-7.3.4): PostgreSQL-7.4
Compiler used (example: gcc 2.95.2) : gcc 3.3.2
Please enter a FULL description of your problem:
We expirience a memory leak with every connection when using an SSL
encrypted TCP connection to connect a postgres database.
A simple code example is included in this mail. It simply opens and
closes a database connection. (You also need a postgresql server set up
for ssl.)
'valgrind' detects the main memory leak (which gets bigger with every
connection) to be in libcrypto.so.0.9.7. But you can also verify the
increased memory consumption using 'ps axl', if you add a 'sleep(..);'
at the end of the program.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
/*
* begin leak.c
*/
#include
#include
int main()
{
int i;
PGconn *conn;
for (i = 0; i < 10; i ++)
{
conn = PQconnectdb("host=... dbname=template1 ... requiressl=1");
if (PQstatus(conn) == CONNECTION_BAD)
{
fprintf(stderr, "Error: %s", PQerrorMessage(conn));
PQfinish(conn);
exit(1);
}
PQfinish(conn);
}
return 0;
}
/*
* end leak.c
*/
$ gcc leak.c -lpq -o leak
$ valgrind --leak-check=yes --error-limit=no ./leak
If you know how this problem might be fixed, list the solution below:
-
---(end of broadcast)---
TIP 8: explain analyze is your friend
[BUGS] Bug in pg_restore or in postmaster itself?
When using "pg_restore -S postgres -s -vcd DBNAME bkupfile" on an existing database, I get the following error: pg_restore: connecting to database for restore pg_restore: dropping RULE au_d_assigned_template pg_restore: dropping RULE au_u_assigned_template ... More rules, triggers, constraints, indexes and functions removed pg_restore: dropping ACL au_assigned_template pg_restore: dropping TABLE au_assigned_template pg_restore: NOTICE: rule au_d_assigned_template on table assigned_template depends on table au_assigned_template pg_restore: NOTICE: rule au_u_assigned_template on table assigned_template depends on table au_assigned_template pg_restore: [archiver (db)] could not execute query: ERROR: Cannot drop table au_assigned_template because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too pg_restore: *** aborted because of error I find it odd that it refuses to drop table au_assigned_template because the two rules depend on it when the rules have already been dropped. If I use the -vCd OTHERDB option and no database exists, it works fine. I'm using version 7.3.4 on RHEL 3. Joseph ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Seg Fault when using modules linked both to libpq and libodbcpsql.
I'm not really sure how to go about debugging this, but when I use PHP to create large objects using libpq, with the php odbc module installed, I get the following seg fault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1226627936 (LWP 28034)] 0xb69f7987 in CC_send_function () from /usr/lib/libodbcpsql.so.2 (gdb) where #0 0xb69f7987 in CC_send_function () from /usr/lib/libodbcpsql.so.2 #1 0xb6a06940 in lo_creat () from /usr/lib/libodbcpsql.so.2 #2 0xb69c6c23 in lo_import () from /usr/lib/libpq.so.3 #3 0xb69e4121 in zif_pg_lo_import (ht=2, return_value=0x8307424, this_ptr=0x0, return_value_used=1) at /usr/src/debug/php-4.3.2/ext/pgsql/pgsql.c:2099 #4 0xb697a542 in zend_assign_to_variable_reference () from /usr/local/Zend/lib/Optimizer-2.1.0/php-4.3.x/ZendOptimizer.so #5 0x0002 in ?? () #6 0x08307424 in ?? () When I don't have the php odbc module installed, no seg fault occurs. What's my next step in working this out? It appears that somehow that libodbcpsql stuff is interfering with libpq. Are there some symbols that could be clobbering each other? I'm running postgresql 7.3.4 on RHL 9 with PHP 4.3.2 and Apache 2.0.46 Joseph ---(end of broadcast)--- TIP 3: 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] Failed regression test in postgresql-7.4
If PostgreSQL failed to compile on your computer or you found a bug that is likely to be specific to one platform then please fill out this form and e-mail it to [EMAIL PROTECTED] To report any other bug, fill out the form below and e-mail it to [EMAIL PROTECTED] If you not only found the problem but solved it and generated a patch then e-mail it to [EMAIL PROTECTED] instead. Please use the command "diff -c" to generate the patch. You may also enter a bug report at http://www.postgresql.org/ instead of e-mail-ing this form. POSTGRESQL BUG REPORT TEMPLATE Your name : Lane Hoy Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Intel Pentium 4 Operating System (example: Linux 2.0.26 ELF) : Linux-2.4.23 ELF, Gentoo distribution PostgreSQL version (example: PostgreSQL-7.4): PostgreSQL-7.4 Compiler used (example: gcc 2.95.2) : gcc 3.3.2, glibc-2.3.2-r9 Please enter a FULL description of your problem: Regression test failed at the createdb stage. Context below: All of PostgreSQL successfully made. Ready to install. make -C src/test check make[1]: Entering directory `/usr/local/src/postgresql-7.4/src/test' make -C regress check make[2]: Entering directory `/usr/local/src/postgresql-7.4/src/test/regress' sed -e 's,@bindir@,/usr/local/pgsql/bin,g' \ -e 's,@libdir@,/usr/local/pgsql/lib,g' \ -e 's,@pkglibdir@,/usr/local/pgsql/lib,g' \ -e 's,@datadir@,/usr/local/pgsql/share,g' \ -e 's/@VERSION@/7.4/g' \ -e 's/@host_tuple@/i686-pc-linux-gnu/g' \ -e 's,@GMAKE@,make,g' \ -e 's/@enable_shared@/yes/g' \ -e 's/@GCC@/yes/g' \ pg_regress.sh >pg_regress chmod a+x pg_regress gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../src/interfaces/libpq -I../../../src/include -D_GNU_SOURCE -I/usr/local/include -I/usr/local/ssl/include -c -o regress.o regress.c gcc -shared -o regress.so regress.o sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' input/copy.source >sql/copy.sql sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' input/create_function_1.source >sql/create_function_1.sql sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' input/create_function_2.source >sql/create_function_2.sql sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' input/misc.source >sql/misc.sql sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' input/constraints.source >sql/constraints.sql sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' output/copy.source >expected/copy.out sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' output/create_function_1.source >expected/create_function_1.out sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' output/create_function_2.source >expected/create_function_2.out sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' output/misc.source >expected/misc.out sed -e 's,@abs_srcdir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's,@abs_builddir@,/usr/local/src/postgresql-7.4/src/test/regress,g' -e 's/@DLSUFFIX@/.so/g' output/constraints.source >expected/constraints.out make -C ../../../contrib/spi refint.so autoinc.so make[3]: Entering directory `/usr/local/src/postgresql-7.4/contrib/spi' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DREFINT_VERBOSE -I. -I../../src/include -D_GNU_SOURCE -I/usr/local/include -I/usr/local/ssl/include -c -o refint.o refint.c gcc -shared -o refint.so refint.o gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DREFINT_VERBOSE -I. -I../../src/include -D_GNU_SOURCE -I/usr/local/include -I/usr/local/ssl/include -c -o auto
Re: [BUGS] Conflicts with autoconf macroses
Tom Lane wrote: Olleg <[EMAIL PROTECTED]> writes: It's bug, autoconf headers may not be included in "library headers". If you think it's a bug you'd better complain to the autoconf people. pg_config.h is generated entirely by autoconf tools. The most libraries use autoheader, but don't generate such error. Generation of pg_config.h is ok. The only mistake is include such autoconf header in headers designed to use with external programs, spi modules in this case. Autoconf header must be included in source directly or included in headers for internal use only. And don't be installed along with other library headers. ---(end of broadcast)--- TIP 3: 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] Migration 7.3 to 7.4 Numeric values using PQ_ interface
Hi, I have been using the C libraries with version 7.33 to retrieve data with success. Now I have migrated to 7.4., although using the psql client all looks fine my integer values returned through the programmatic interface are wild, e.g. should be 101 and is 7236487. Char and varchar are fine. Has something changed radically in this release that could cause a binary incompatibility? Any suggestions? Thanks, Paul Download Yahoo! Messenger now for a chance to win Live At Knebworth DVDs http://www.yahoo.co.uk/robbiewilliams ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Conflicts with autoconf macroses
Olleg writes: > > because of this kind of name conflict. There is a contributed macro that > > automatically prefixes all macro names so they don't conflict. May be > > worth checking out. > > ??? Please explain. http://ac-archive.sourceforge.net/guidod/ax_prefix_config_h.html ---(end of broadcast)--- TIP 3: 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] BUG #1000: Testing new bugs form.
The following bug has been logged online: Bug reference: 1000 Logged by: Dave Page Email address: [EMAIL PROTECTED] PostgreSQL version: 7.5 Dev Operating system: FreeBSD www.postgresql.com 4.8-STABLE FreeBSD 4.8-STABLE #5: Sat Sep 20 14:56:14 ADT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/kernel i386 Description:Testing new bugs form. Details: This is a test sent from the new bug reporting form at http://www.postgresql.org/bugform.php. I'd appreciate an email from someone to let me know that this made it onto the bugs list OK as I'm not currently subscribed. Cheers, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] BUG #1000: Testing new bugs form.
PostgreSQL Bugs List wrote: The following bug has been logged online: Bug reference: 1000 Logged by: Dave Page Email address: [EMAIL PROTECTED] PostgreSQL version: 7.5 Dev Operating system: FreeBSD www.postgresql.com 4.8-STABLE FreeBSD 4.8-STABLE #5: Sat Sep 20 14:56:14 ADT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/kernel i386 Description:Testing new bugs form. Details: This is a test sent from the new bug reporting form at http://www.postgresql.org/bugform.php. I'd appreciate an email from someone to let me know that this made it onto the bugs list OK as I'm not currently subscribed. Cheers, Dave. Got it. Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Wierd MD5-authentication crash on Solaris 8
Josh Berkus <[EMAIL PROTECTED]> writes: > Summary: attempting to connect via MD5 authentication as a user > who has no password triggers a core dump of Postmaster. [...] > Core dump file is available. Can you post a stacktrace? (Building the postmaster with debugging symbols first would be nice.) -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] libpq3 + ssl memory leak
Olaf Hartmann <[EMAIL PROTECTED]> writes: > We expirience a memory leak with every connection when using an SSL > encrypted TCP connection to connect a postgres database. I can verify this locally. Unfortunately, my copy of valgrind doesn't seem to be picking up the debugging symbols for OpenSSL, which makes it difficult to track down if this is a fault in OpenSSL or libpq. If someone else wants to tackle this, go ahead -- my plate is full until around December 10th. Otherwise I'll look into it then. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
