[BUGS] BUG #2266: SQL_ATTR_CONNECTION_DEAD always returns SQL_CD_TRUE
The following bug has been logged online: Bug reference: 2266 Logged by: Gerhard Lutz Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Windows XP SP2 Description:SQL_ATTR_CONNECTION_DEAD always returns SQL_CD_TRUE Details: I want to upgrade my PostgreSQL server from 8.0.4 to 8.1.3. My C++ application connects to the database via ODBC (ODBC driver: PostgreSQL Unicode). In 8.0.4 I was able to check after an error if the database connection get lost. ::SQLGetConnectAttr(g_hDBConnection, SQL_ATTR_CONNECTION_DEAD, &uConnectionDead, 0, &nLen); returned SQL_CD_TRUE or SQL_CD_FALSE. In 8.1.3 this function always returns SQL_CD_TRUE, even when the database connection is still available. Has this to do with ODBC 3.5 or is it a bug in the ODBC driver? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2267: Accessing large objects via ODBC
The following bug has been logged online: Bug reference: 2267 Logged by: Gerhard Lutz Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Windows XP SP2 Description:Accessing large objects via ODBC Details: I want to upgrade my PostgreSQL server from 8.0.4 to 8.1.3. My C++ application connects to the database via ODBC (ODBC driver: PostgreSQL Unicode). I've installed 8.1.3 with "large objects (lo)" and created a table CREATE testdata (id integer not null, buffer lo); So far this worked. Now if I want to get the 'buffer' column ::SQLExecDirect(m_hStmt, (unsigned char*)"SELECT buffer FROM testdata WHERE id=6", SQL_NTS); ::SQLFetch(m_hStmt); ::SQLGetData(m_hStmt, nCol, SQL_C_BINARY, pBuffer, nPacketSize, &sdODataLength); I get the error message "Received an unsupported type from Postgres. (14)" In PostgreSQL 8.0.4 this worked without a problem. In 8.1.3 I can also see in pgAdmin III that there are no functions lo_in(lo) and lo_out(lo) in the tree. Perhaps this is an installation bug in 8.1.3? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2246: Bad malloc interactions: ecpg, openssl
On Wed, 15 Feb 2006, Tom Lane wrote: > Andrew Klosterman <[EMAIL PROTECTED]> writes: > > With the debug binaries, I was able to step through the program and get to > > what appears to be the function where it bails: line 1166 of > > postgresql-8.1.0/src/interfaces/libpq/fe-secure.c where SSL_free() is > > called. > > BTW, is the address that glibc says is corrupted consistent from run to > run? If so, you could narrow down the problem pretty quickly by setting > a hardware watchpoint on that address with gdb. Any hits that are not > from the malloc subroutines are probably the source of the problem. > > regards, tom lane The address given by the error message is consistent. But, setting a break/watch point for it has been troublesome. A watchpoint can't be set until the memory is mapped in. I have narrowed down the time that the memory is mapped in to being somewhere in a call to PQconnectPoll() from within connectDBComplete() in src/interfaces/libpq/fe-connect.c. With the watchpoint set, though, the debugger isn't breaking the execution of the program until the error manifests itself. Digging around, I can't come up with a way to get information on the arguments and return results from malloc() every time it is called. "strace" only does system calls. The output I get from "ltrace" is not useful and no options I can see appear to improve the situation. So, I'm kinda stuck. This bug might be one that gets away... --Andrew J. Klosterman [EMAIL PROTECTED] ---(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 #2265: CREATE TABLE when AUTOCOMMIT is OFF
The following bug has been logged online: Bug reference: 2265 Logged by: Gerhard Lutz Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Windows XP SP2 Description:CREATE TABLE when AUTOCOMMIT is OFF Details: I want to upgrade my PostgreSQL server from 8.0.4 to 8.1.3. My application connects to the database via ODBC. After connecting to the database I set the AUTOCOMMIT mode to OFF. ::SQLSetConnectAttr(g_hDBConnection, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF), 0); Now, if I want do create a table via ODBC, e.g. "CREATE TABLE db_version ( hv integer, uv integer, nv integer, r integer, rel integer)" , I get the error message "Error while executing the query; ERROR: current transaction is aborted, commands ignored until end of transaction block (7)" In PostgreSQL 8.0.4 I was able to create a table in AUTOCOMMIT mode OFF without any error. Is this a bug in 8.1.3? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
I appreciate you guys looking at this bug. Taking Tom's suggestion that it might be a system crypt implementation issue I upgraded OpenSSL from 0.9.7e to 0.9.7i. I also upgraded any other libraries that were installed with the word crypt. After running ldconfig I then recompiled Postgres 8.1.2 againt the newly installed libraries and ended up with the same results. Michael's standalone testcase was blowing up the memory usage very quickly. I did notice as I was doing more testing that if i disconnect my client after running subsequent queries that the memory usage drops due to the server process getting killed. Other Possibly Useful info: CFLAGS="-O3 -march=pentium4 -pipe" MAKEOPTS="-j3" I'm going to try compiling with the -ssl USE flag set to avoid any external libraries and attempt to duplicate this bug. I'll let you know what results I find. -Daniel On 2/15/06, Michael Fuhr <[EMAIL PROTECTED]> wrote: On Wed, Feb 15, 2006 at 01:43:18PM -0500, Tom Lane wrote:> Michael Fuhr <[EMAIL PROTECTED]> writes:> > I can reproduce this in 8.1.3 on FreeBSD 6.0 and Solaris 9. Here's > > a standalone test case:>> > SELECT crypt(x::text, '$1$salt') FROM generate_series(1, 500) AS g(x);>> Interesting, because I see no leak with this example on Fedora 4 or> HPUX. Platform dependency is sounding more and more likely. Did you test OpenSSL builds? Both of my systems are built withOpenSSL and that causes pgcrypto to use different code in someplaces (e.g., px_find_digest() in internal.c and openssl.c). I'llbuild and test a non-OpenSSL version when I get a chance. --Michael Fuhr
Re: [BUGS] BUG #2260: PGCrypto Memory Problem
On Wed, Feb 15, 2006 at 03:02:45PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > My non-OpenSSL build shows no memory leak, so the leak and OpenSSL
> > seem to be correlated. I'd be more inclined to suspect a bug in
> > pgcrypto's OpenSSL-specific code than in OpenSSL itself. Will keep
> > digging.
>
> The problem appears to be here:
>
> static void
> digest_finish(PX_MD * h, uint8 *dst)
> {
> EVP_MD_CTX *ctx = (EVP_MD_CTX *) h->p.ptr;
> const EVP_MD *md = EVP_MD_CTX_md(ctx);
>
> EVP_DigestFinal(ctx, dst, NULL);
>
> /*
> * Some builds of 0.9.7x clear all of ctx in EVP_DigestFinal. Fix it by
> * reinitializing ctx.
> */
> EVP_DigestInit(ctx, md);
> }
>
> It looks like this results in a leak of the entire OpenSSL context for
> each call to pg_crypt. Marko, I trust you've got a better solution for
> this ...
Seems it's another bug in OpenSSL backwards compatibility code.
'man EVP_DigestInit':
0.9.7g:
EVP_DigestFinal() is similar to EVP_DigestFinal_ex()
except the digest context ctx is automatically cleaned up.
0.9.6c:
EVP_DigestFinal() retrieves the digest value from ctx
and places it in md. If the s parameter is not NULL then the
number of bytes of data written (i.e. the length of the digest)
will be written to the integer at s, at most EVP_MAX_MD_SIZE
bytes will be written. After calling EVP_DigestFinal() no
additional calls to EVP_DigestUpdate() can be made, but
EVP_DigestInit() can be called to initialize a new digest
operation.
But I have planned converting it to newer *_ex interface,
I just didn't bother as I hoped OpenSSL compatibility code
works fine. Seems they don't do much testing of older
interfaces, so the fix should be conversion of digest
functions to newer interface.
I'll send a patch ASAP.
--
marko
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2265: CREATE TABLE when AUTOCOMMIT is OFF
On Thu, Feb 16, 2006 at 01:21:18PM +, Gerhard Lutz wrote: > "Error while executing the query; > ERROR: current transaction is aborted, commands ignored until end of > transaction block (7)" Some previous command failed so no more commands in this transaction will be allowed. If you don't know what command failed then you could configure query logging. > In PostgreSQL 8.0.4 I was able to create a table in AUTOCOMMIT mode OFF > without any error. Is this a bug in 8.1.3? The error is apparently happening before the CREATE TABLE command. Let's see what earlier command failed and why. -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2269: cannot connect to postgres database on Linux
The following bug has been logged online: Bug reference: 2269 Logged by: Ken Email address: [EMAIL PROTECTED] PostgreSQL version: 7.3.4 Operating system: Linux Description:cannot connect to postgres database on Linux Details: I just downloaded pgAdminIII for Windows to use to connect to our postgres databases on Linux. The problem I have is that when I enter the password, I get this error: Error has occurred Error connecting to the server: missing "=" after """ in connection info string. The passwords to our databases contain the characters ; and ', which is what is probably causing this problem. Can this be resolved or is there a temp fix to get around this problem? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2268: initdb fails to initialize database cluster with error "Access is denied"
The following bug has been logged online: Bug reference: 2268 Logged by: James Hughes Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Windows 2003 (Server) Description:initdb fails to initialize database cluster with error "Access is denied" Details: When we try and initialize a database cluster using initdb.exe we are getting the following output. -- OUTPUT from dbinit.exe -- The files belonging to this database system will be owned by user "user1". This user must also own the server process. The database cluster will be initialized with locale English_United Kingdom.1252. creating directory c:/dataa ... ok creating directory c:/dataa/global ... ok creating directory c:/dataa/pg_xlog ... ok creating directory c:/dataa/pg_xlog/archive_status ... ok creating directory c:/dataa/pg_clog ... ok creating directory c:/dataa/pg_subtrans ... ok creating directory c:/dataa/pg_twophase ... ok creating directory c:/dataa/pg_multixact/members ... ok creating directory c:/dataa/pg_multixact/offsets ... ok creating directory c:/dataa/base ... ok creating directory c:/dataa/base/1 ... ok creating directory c:/dataa/pg_tblspc ... ok selecting default max_connections ... Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. 10 selecting default shared_buffers ... Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. Access is denied. 50 creating configuration files ... ok creating template1 database in c:/dataa/base/1 ... ok initializing pg_authid ... Access is denied. child process was terminated by signal 1 initdb: removing data directory "c:/dataa" -- end: OUTPUT from dbinit.exe -- user1 is a user without administrative rights. I have checked all the directories and the user has permissons to write to the data directory, and read other files it requires. I also tried the Windows installer (MSI) from pgFoundry. This too is having the same problem. We have two machines which this problem occurs on, one of which originally the initialization would work on. I have checked all the user rights asssignments, and even given the postgres user (user1 in the above output from dbinit.exe) all user rights. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
