Gaurav Srivastava | 12 Dec 11:31 2014

High CPU shoot during poll retry


Hi All,

In ODBC library later to change done as part of commit Title  "Rip out broken retry/timeout logic in SOCK_wait_for_ready." in file socket.c

Now  the cpde snippet for SOCK_wait_for_ready() is like:

       do {
#ifdef  HAVE_POLL
                fds.fd = sock->socket;
                fds.events = output ? POLLOUT : POLLIN;
                fds.revents = 0;
                ret = poll(&fds, 1, nowait ? 0 : -1);
mylog("!!!  poll ret=%d revents=%x\n", ret, fds.revents);
#else
                FD_ZERO(&fds);
                FD_ZERO(&except_fds);
                FD_SET(sock->socket, &fds);
                FD_SET(sock->socket, &except_fds);
                if (nowait)
                {   
                        tm.tv_sec = 0;
                        tm.tv_usec = 0;
                }   
                ret = select((int) sock->socket + 1, output ? NULL : &fds, output ? &fds : NULL, &except_fds, nowait ? &tm : NULL);
#endif /* HAVE_POLL */
                gerrno = SOCK_ERRNO;
        } while (ret < 0 && EINTR == gerrno);



So whenever there is no fd is ready to be read it will immediately return and solve the issue of infinite query hung but  due to immediate return it will go for continuous retries and causing CPU to shoot very high.This is one of the case we are suffering in our scenario after upgrading ODBC.

One way is to put usleep  from post to every call  of SOCK_wait_for_ready() to solve this,but would request if a better patch can be available to fix this issue.
Please suggest.

Thanks and Regards,
Gaurav Srivastava | Associate Consultant
GlobalLogic
P +91.120.4342000.2920  M +91.9953996631  S ta5ramn1
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
Michael Paquier | 10 Dec 06:32 2014
Picon

Regression failures for test col_attributes.sql introduced recently

Hi all,

I spotted a failure with test col_attributes that has been introduced
recently by commit ac52d71 when running the tests on an Archlinux VM.
Diffs are attached. It seems like SQL_DESC_OCTET_LENGTH is not that
consistent across platforms.
Regards,
-- 
Michael
Attachment (regression.diffs): application/octet-stream, 2973 bytes

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Rasna T | 9 Dec 12:09 2014
Picon

Release notes for psqlODBC 09.03.0400

Hi,
Can you please update release notes for latest release 09.03.0400?

http://psqlodbc.projects.pgfoundry.org/docs/release.html

Regards,
Rasna.

Eric Hill | 5 Dec 19:56 2014

SQLFreeHandle() takes eons when running debug

Hey,

 

Not sure how this could be the PostgreSQL ODBC driver’s fault, but when I run a debug build of my application, calls to SQLFreeHandle() to free a statement can have for quite a long time (we’re talking a minute or two) before proceeding.  This is Windows, 64-bit Unicode, version 9.03.03 of the PG ODBC driver.   The call stack looks like this when paused:

 

                ntdll.dll!RtlCompareMemoryUlong()  + 0x10 bytes          

               ntdll.dll!RtlpFreeHeap()  + 0x113f bytes

               ntdll.dll!RtlFreeHeap()  + 0x1df bytes    

               ntdll.dll!RtlDebugFreeHeap()  + 0x23f bytes       

               ntdll.dll!RtlpFreeHeap()  + 0x7d5b7 bytes            

               ntdll.dll!RtlFreeHeap()  + 0x1df bytes    

               msvcr100.dll!free()  + 0x1c bytes             

               psqlodbc35w.dll!00007ff97bc7c827()      

                [Frames below may be incorrect and/or missing, no symbols loaded for psqlodbc35w.dll]            

               psqlodbc35w.dll!00007ff97bc7656b()     

                psqlodbc35w.dll!00007ff97bc76044()     

                psqlodbc35w.dll!00007ff97bc761c7()      

                psqlodbc35w.dll!00007ff97bc88781()     

                psqlodbc35w.dll!00007ff97bc66bda()     

                odbc32.dll!FreeStmt()  + 0x2c5 bytes     

               odbc32.dll!SQLFreeHandle()  + 0x2a0 bytes        

>             Jmp.exe!DBContext::freeStmt(void * & hstmt=0x000000001f032030)  Line 1644 + 0x14 bytes      C++

 

Running a release build, no such delay.  We don’t see anything like this for SQL Server, Oracle, DB2, Teradata, or MySQL ODBC drivers.  Anyone run into this before that can suggest a fix or workaround?

 

Thanks,

 

Eric

 

Nathanael Terrien | 5 Dec 10:14 2014
Picon

Exponential processing time for multiple SELECT FOR UPDATE / UPDATE in a single transaction with PostgreSQL 9.x ?

Hi List.

Our application does something like this, through psqlodbc :
------------------------------------------------------------------------------
Open transaction (« BEGIN »)
FOR x TO y STEP 1
   Do Stuff
   « SELECT col1 FROM table1 WHERE condition1 FOR UPDATE ; »
  Do Stuff
  « UPDATE table1 SET col1=z WHERE condition1 ; »
  Do Stuff
NEXT x
End transaction (« COMMIT »)
------------------------------------------------------------------------------

Against PostgreSQL 8.4 : no problem.
Against PostgreSQL 9.x : starting at about a few hundred loops (locks), the process slows down, and
continues to slow down exponentially, until the COMMIT happens.

We tried with different languages (C#, Omnis Studio, plain plpgsql ...), different versions of
psqlodbc (8.4.2 to 9.3.x), different versions of PostgreSQL (8.4, 9.3, 9.4 RC1) , without psqlODBC ...
and it all comes down to this : 
The slow-down only happens with psqlodbc and PostgreSQL 9.x

So we guess it's abug ?

Regards,
Nathanael TERRIEN
Must  Informatique

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Talha OZ | 3 Dec 06:09 2014
Picon

psqlodbcw.so symbol lookup errors

isql works with the following errors.
stata fails to connect which I believe because of the errors.
how can I fix these errors?
Thanks !


Here is some info about the installed libraries and configuration:

installed postgresql-devel-8.1.23-1.el5_6.1.x86_64.rpm

(note if I try to  ./configure --with-libpq=/usr/lib64/libpq it fails with specified pg_config not found although it is in /usr/bin/)

installed psqlodbc-08.04.0200 from source


[toz <at> ~]$ /usr/lib/libiodbc<TAB>

libiodbcinst.so.2       libiodbcinst.so.2.1.18  libiodbc.so.2           libiodbc.so.2.1.18 

---------------------------------------

[toz <at> ~]$ /usr/lib/libodbc<TAB>

libodbccr.so              libodbcdrvcfg2S.so.1      libodbcminiS.so.1.0.0     libodbcpsql.so            libodbcpsqlS.so.1.0.0

libodbccr.so.1            libodbcdrvcfg2S.so.1.0.0  libodbcmyS.so             libodbcpsql.so.1          libodbc.so

libodbccr.so.1.0.0        libodbcinst.so            libodbcmyS.so.1           libodbcpsql.so.1.0.0      libodbc.so.1

libodbcdrvcfg1S.so        libodbcinst.so.1          libodbcmyS.so.1.0.0       libodbcpsql.so.2          libodbc.so.1.0.0

libodbcdrvcfg1S.so.1      libodbcinst.so.1.0.0      libodbcnnS.so             libodbcpsql.so.2.0.0      libodbctxtS.so

libodbcdrvcfg1S.so.1.0.0  libodbcminiS.so           libodbcnnS.so.1           libodbcpsqlS.so           libodbctxtS.so.1

libodbcdrvcfg2S.so        libodbcminiS.so.1         libodbcnnS.so.1.0.0       libodbcpsqlS.so.1         libodbctxtS.so.1.0.0

---------------------------------------

[toz <at> ~]$ /usr/lib64/libodbc<64>

libodbccr.so              libodbcdrvcfg2S.so.1      libodbcminiS.so.1.0.0     libodbcpsql.so            libodbcpsqlS.so.1.0.0

libodbccr.so.1            libodbcdrvcfg2S.so.1.0.0  libodbcmyS.so             libodbcpsql.so.1          libodbc.so

libodbccr.so.1.0.0        libodbcinst.so            libodbcmyS.so.1           libodbcpsql.so.1.0.0      libodbc.so.1

libodbcdrvcfg1S.so        libodbcinst.so.1          libodbcmyS.so.1.0.0       libodbcpsql.so.2          libodbc.so.1.0.0

libodbcdrvcfg1S.so.1      libodbcinst.so.1.0.0      libodbcnnS.so             libodbcpsql.so.2.0.0      libodbctxtS.so

libodbcdrvcfg1S.so.1.0.0  libodbcminiS.so           libodbcnnS.so.1           libodbcpsqlS.so           libodbctxtS.so.1

libodbcdrvcfg2S.so        libodbcminiS.so.1         libodbcnnS.so.1.0.0       libodbcpsqlS.so.1         libodbctxtS.so.1.0.0

---------------------------------------

[toz <at> ~]$ cat /etc/odbc.ini 

[ODBC Data Sources]

PostgreSQL = PostgreSQL 


[PostgreSQL]

Description = ODBC for PostgreSQL

Driver = /usr/local/lib/psqlodbcw.so

Database = wellness


[ODBC]

InstallDir=/usr/local/lib


[Default]

Driver = /usr/lib64/libodbcpsql.so

---------------------------------------

[toz <at> ~]$ cat /etc/redhat-release 

Red Hat Enterprise Linux Server release 5.7 (Tikanga)

---------------------------------------

[~]$ cat .bash_profile 

export ODBCSYSINI=/etc

export ODBCINI=/etc/odbc.ini

export LD_LIBRARY_PATH=/usr/local/lib

---------------------------------------

[psqlodbc-08.04.0200]$ LD_DEBUG=libs isql PostgreSQL

     30006: find library=libodbc.so.1 [0]; searching

     30006: search path=/usr/local/lib/tls/x86_64:/usr/local/lib/tls:/usr/local/lib/x86_64:/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/tls/x86_64/libodbc.so.1

     30006:   trying file=/usr/local/lib/tls/libodbc.so.1

     30006:   trying file=/usr/local/lib/x86_64/libodbc.so.1

     30006:   trying file=/usr/local/lib/libodbc.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/usr/lib64/libodbc.so.1

     30006:

     30006: find library=libodbcinst.so.1 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libodbcinst.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/usr/lib64/libodbcinst.so.1

     30006:

     30006: find library=libdl.so.2 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libdl.so.2

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libdl.so.2

     30006:

     30006: find library=libpthread.so.0 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libpthread.so.0

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libpthread.so.0

     30006:

     30006: find library=libc.so.6 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libc.so.6

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libc.so.6

     30006:

     30006:

     30006: prelink checking: ok

     30006:

     30006: calling init: /lib64/libpthread.so.0

     30006:

     30006:

     30006: calling init: /lib64/libc.so.6

     30006:

     30006:

     30006: calling init: /lib64/libdl.so.2

     30006:

     30006:

     30006: calling init: /usr/lib64/libodbcinst.so.1

     30006:

     30006:

     30006: calling init: /usr/lib64/libodbc.so.1

     30006:

     30006:

     30006: initialize program: isql

     30006:

     30006:

     30006: transferring control: isql

     30006:

     30006: find library=libnss_files.so.2 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libnss_files.so.2

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libnss_files.so.2

     30006:

     30006:

     30006: calling init: /lib64/libnss_files.so.2

     30006:

     30006:

     30006: calling init: /usr/lib64/gconv/ISO8859-1.so

     30006:

     30006: /usr/lib64/gconv/ISO8859-1.so: error: symbol lookup error: undefined symbol: gconv_end (fatal)

     30006: find library=libssl.so.6 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libssl.so.6

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libssl.so.6

     30006:

     30006: find library=libpq.so.4 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libpq.so.4

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/usr/lib64/libpq.so.4

     30006:

     30006: find library=libgssapi_krb5.so.2 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libgssapi_krb5.so.2

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/usr/lib64/libgssapi_krb5.so.2

     30006:

     30006: find library=libkrb5.so.3 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libkrb5.so.3

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/usr/lib64/libkrb5.so.3

     30006:

     30006: find library=libcom_err.so.2 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libcom_err.so.2

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libcom_err.so.2

     30006:

     30006: find library=libk5crypto.so.3 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libk5crypto.so.3

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/usr/lib64/libk5crypto.so.3

     30006:

     30006: find library=libcrypto.so.6 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libcrypto.so.6

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libcrypto.so.6

     30006:

     30006: find library=libz.so.1 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libz.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libz.so.1

     30006:

     30006: find library=libcrypt.so.1 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libcrypt.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libcrypt.so.1

     30006:

     30006: find library=libresolv.so.2 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libresolv.so.2

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libresolv.so.2

     30006:

     30006: find library=libnsl.so.1 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libnsl.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libnsl.so.1

     30006:

     30006: find library=libkrb5support.so.0 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libkrb5support.so.0

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/usr/lib64/libkrb5support.so.0

     30006:

     30006: find library=libkeyutils.so.1 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libkeyutils.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libkeyutils.so.1

     30006:

     30006: find library=libselinux.so.1 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libselinux.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libselinux.so.1

     30006:

     30006: find library=libsepol.so.1 [0]; searching

     30006: search path=/usr/local/lib (LD_LIBRARY_PATH)

     30006:   trying file=/usr/local/lib/libsepol.so.1

     30006: search cache=/etc/ld.so.cache

     30006:   trying file=/lib64/libsepol.so.1

     30006:

     30006:

     30006: calling init: /lib64/libsepol.so.1

     30006:

     30006:

     30006: calling init: /lib64/libselinux.so.1

     30006:

     30006:

     30006: calling init: /lib64/libkeyutils.so.1

     30006:

     30006:

     30006: calling init: /lib64/libresolv.so.2

     30006:

     30006:

     30006: calling init: /usr/lib64/libkrb5support.so.0

     30006:

     30006:

     30006: calling init: /lib64/libnsl.so.1

     30006:

     30006:

     30006: calling init: /lib64/libcrypt.so.1

     30006:

     30006:

     30006: calling init: /lib64/libz.so.1

     30006:

     30006:

     30006: calling init: /lib64/libcrypto.so.6

     30006:

     30006:

     30006: calling init: /usr/lib64/libk5crypto.so.3

     30006:

     30006:

     30006: calling init: /lib64/libcom_err.so.2

     30006:

     30006:

     30006: calling init: /usr/lib64/libkrb5.so.3

     30006:

     30006:

     30006: calling init: /usr/lib64/libgssapi_krb5.so.2

     30006:

     30006:

     30006: calling init: /lib64/libssl.so.6

     30006:

     30006:

     30006: calling init: /usr/lib64/libpq.so.4

     30006:

     30006:

     30006: calling init: /usr/local/lib/psqlodbcw.so

     30006:

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDriverLoad (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDriverUnload (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLAllocConnect (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLAllocEnv (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLAllocStmt (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLAllocHandleStd (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLBrowseConnectA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLColAttributeA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLColAttributes (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLColAttributesA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLColAttributesW (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLColumnPrivilegesA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLColumnsA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLConnectA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDataSourcesA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDescribeColA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDriverConnectA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDrivers (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDriversA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLDriversW (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLError (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLErrorA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLErrorW (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLExecDirectA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLForeignKeysA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLFreeEnv (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLFreeConnect (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetConnectAttrA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetConnectOption (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetConnectOptionA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetConnectOptionW (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetCursorNameA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetDescFieldA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetDescRecA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetDescRecW (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetDiagFieldA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetInfoA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetStmtAttrA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetStmtOption (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetTypeInfoA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLNativeSqlA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLParamOptions (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLPrepareA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLPrimaryKeysA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLProcedureColumnsA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLProceduresA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetConnectAttrA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetConnectOption (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetConnectOptionA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetConnectOptionW (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetCursorNameA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetDescFieldA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetScrollOptions (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetStmtAttrA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSetStmtOption (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLSpecialColumnsA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLStatisticsA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLTablePrivilegesA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLTablesA (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLTransact (fatal)

     30006: /usr/local/lib/psqlodbcw.so: error: symbol lookup error: undefined symbol: SQLGetDiagRecA (fatal)

+---------------------------------------+

| Connected!                            |

|                                       |

| sql-statement                         |

| help [tablename]                      |

| quit                                  |

|                                       |

+---------------------------------------+

SQL> 




-Talha
Faith, Jeremy | 2 Dec 13:28 2014

Re: [BUGS] BUG #11767: ODBC driver bug when fetching constant string columns

> On Fri, Oct 24, 2014 at 9:36 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> wrote:
>
> > On Wed, Oct 22, 2014 at 11:22 PM,  <keyurgovande(at)gmail(dot)com> wrote:
> > > The following bug has been logged on the website:
> > >
> > > Bug reference:      11767
> > > Logged by:          Keyur Govande
> > > Email address:      keyurgovande(at)gmail(dot)com
> > > PostgreSQL version: 9.0.3
> > You should update to 9.0.18, you are 3.5 years of bug fixes.
> >
>
> Ah I apologize, I chose the wrong version in the bug report dropdown. This
> bug was observed with the latest driver: psqlodbc-09.03.0300 connecting to
> a Postgres server 9.1.14.
>
I can confirm that this bug exists in psqlodbc-09.03.0300 connecting to PostgreSQL 9.3.5.
>
> >
> > > If we run a SELECT statement like: SELECT id, varchar_col, date_col,
> > 'random
> > > string' as random;
> > > via ODBC, then the last column comes back as junk into PHP.
> > >
> > > In PHP we use the SQL_DESC_OCTET_LENGTH to figure out how many bytes to
> > > allocate. But for that column, SQL_DESC_OCTET_LENGTH returns 0 and we
> > don't
> > > allocate enough space.
> > >
> > > The driver issue seems to be that when SQLColAttributes() is called with
> > > SQL_COLUMN_TYPE for column 'random', it returns SQL_VARCHAR even though
> > the
> > > PG type is PG_TYPE_UNKNOWN. The promotion is happening here:
> > >
> > http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob;f=pgtypes.c;h=4ce7636b69d371d9f511d492c68013f070e3b32a;hb=HEAD#l665
> > >
> > > I think the same promotion needs to happen when fetching octet-length
> > here:
> > >
> > http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob;f=pgtypes.c;h=4ce7636b69d371d9f511d492c68013f070e3b32a;hb=HEAD#l1275
> > >
> > > Thoughts? This is not a problem when using the Vertica ODBC driver for
> > > example.
> > >
> > > A temporary workaround is to use a cast thusly: SELECT id, varchar_col,
> > > date_col, varchar 'random string' as random;
> > > This was reported to the PHP project (
> > https://bugs.php.net/bug.php?id=68087)
> > > but it seems like a Postgres ODBC driver bug.
> > pgsql-odbc is more adapted for a bug report on the ODBC driver. I am
> > moving the thread there.
> > --
> > Michael
> >
Jeremy Faith
Tyco Safety Products/CEM Systems Ltd.

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees
named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not
disseminate, copy or take any action in respect of any information contained in it. If you have received
this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail
and its attachments.

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Michael Paquier | 28 Nov 06:49 2014
Picon

Ignore files generated by odbcini-gen in code tree

Hi all,

The automatically-generated files mentioned in $subject have been
added by recent commit 276cb5e. Attached is a patch to ignore them,
that will prevent their inclusion in the code tree.
Regards,
-- 
Michael

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
developer rohto | 26 Nov 16:01 2014

Pgodbc is thread safe?

Dear all,

Our application will be transplanted from Oracle to PostgreSQL. 
This application based on odbc.

There is a little worry about thread-safe when transplanting.
Oracle odbc support thread safe. Does pgodbc support thread-safe?
Help your response. Thank you very much.

Best wishes~
Sincerely yours, rohto.david
Pavel Raiskup | 18 Nov 10:14 2014
Picon

making the testsuite installable

Hello all.

My issue with current testsuite solution:

  The testsuite requires 'root' account.  Thats needed because successful run
  requires PostgreSQL properly configured and running.  This is hardly
  achievable during package build because (e.g. in Fedora) we build packages
  under non-privileged user.

  Running git testsuite against distributed psqlodbc is not comfortable so
  I doubt users run the testsuite.  Running the testsuite automatically is
  not trivial.

It would be really nice to have the testsuite installed with 'make
install'.  That would allow us to package the testsuite as separated
(sub)package and distribute it to end-users (who should be able to have
enough privileges).  It would also allow me to write privileged scripts
for downstream testing.

Would you be interested in patches implementing this? .. 
* adding option ./configure --enable-dist-tests (default off)
* make tests sub-directory autoreconfed

Pavel

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

蔡珂珂 | 15 Nov 07:47 2014

some questions in psqlodbc

Dear somebody:
    hello, I am eric from beijing. And I am a fresh man in psqlodbc. When I am studing at the psqlodbc source code, I have some questions. 
    In file named "odbcapi.c", the function named "SC_opencheck" are called almost everywhere, and in the function, why return some error when "the cursor is open"? And using git, I saw that change was beening done in 2004-01-06 17:58:22. Oh how old is it, but I can't understande why we can't use a cursor when it is opened or created by some other?
    And  in function "PGAPI_ExtendedFetch" in another file "results.c", which is called by SQLFetch, why seting cursor to start using function "SC_inc_rowset_start" or function "SC_set_rowset_start"?
Because we will maybe get rowdata next or not? 
    Could you understand me? My englist is poor, and I am afraid that I couldn't descript my questions clearly. I am sorry to apologize.

Best wishes!
                                                                                            Eric 
                                                                                            From Beijing 2014-11-15 



Gmane