rohtodeveloper | 20 Oct 13:56 2014

This may be a bug: odbc's function"check_client_encoding" have the same name with postgres's function.

Dear all


I found a problem in the odbc driver on linux platfrom.


Inside the odbc driver,there is a function called check_client_encoding() ,however,there is also a function which has the same name inside the postgres.

once the two functions are in the same process, problems may occur,because the system may choose the wrong function to execute.

If I create a postgres's FUNCTION(myfunc()) using C languageand use this FUNCTION to call the odbc driver(,this problem may happen.


The follow picture explain the situation.

The declaration of the two functions are as follows:       

           UCHAR *check_client_encoding(const UCHAR *sql_string);

           bool check_client_encoding(char **newval, void **extra, GucSource source);



I want to call the odbc's function "check_client_encoding",however it calls the postgres's function "check_client_encoding".

I think this probably is a bug.


Call you help me with this problem?

Thank you so much!




Adrian Klaver | 17 Oct 17:04 2014

Re: PostgreSQL crash at SQLColAttribute()

On 10/17/2014 12:22 AM, Bala krishna Devasani wrote:
> No error message were getting . My application is simply getting crashed
> at function SQLGetInfo().
> i am using linux ubuntu (12.04)
> PostgreSQL:PostgreSQL 9.1
> unixODBC (2.3.2),
> PostgreSQL
> database (9.1),
> psqlodbc driver (3.03) ,
> libodbc++-0.2.3
> Can u please tell me what might be the problem. is it a problem with
> *postgresql odbc driver* (or) *unix odbc driver* ???

Do not have a clue and without more information I doubt it is solvable.


1) What application are using?

2) What are you doing when you use SQLGetInfo()?
     The code that you are using would be helpful.

3) You mentioned something about a trace. Is there information available 
from that trace?

4) If not can you set up a trace?

5) Have you set up logging in ODBC?
    If so what is in the logs?
    If not set it up and then run the code.

> Thanks & Regards
> Balakrishna

Adrian Klaver
adrian.klaver <at>


Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

Andreas Buschka | 17 Oct 14:17 2014

Linking tables from MS Access 2013 works fine, but cannot get table and column comments

Hello all,


I am sorry if this question has already been answered, but I could not find it in either the FAQs or by searching this mailing list.


We currently have the following setup:

-   pgsql Server 9.3 running on Windows x64

-   pgODBC driver 9.0.3 on Windows x64 clients (using 32-bit version due to MS Office version)

-   Microsoft Access 2010 (2013 on some workstations) with all patches


We have created some tables and commented them, like this:


COMMENT ON TABLE our_table_name

  IS 'A comment about this table.';

COMMENT ON COLUMN our_table_name.pk_our_table IS 'A comment about the primary key column.';


This works fine, I can see the comments in pgAdmin. However, when I link these tables into a new Microsoft Access database (created a DSN in the 32-bit ODBC admin using default settings), the table and its fields are linked correctly, however, not a single comment, neither for the table nor for any column, is imported into Access. This is rather unfortunate, because our data model is well-documented, and we would like to have this information available in Access as well.


I tried playing with various settings of the ODBC connection, but none of them had any effect on the table link. Is importing the comments possible at all?


All the best,



Oliver Freyd | 17 Oct 12:07 2014

[PATCH] SQLFreeStmt deletes params, but does not reset the stmt->prepared state.


In ResolveOneParam (convert.c:4586) there is code that converts boolean 
'-1' to '1'. This is necessary for MS Access because it uses -1 as true 

In my application, an Access 2013 frontend with a postgresql backend,
sometimes this conversion did not work, and the backend would fail like 

invalid input syntax for type boolean: "-1" at character 399

The statement is like this:

DELETE FROM "public"."someview" WHERE "id" = 13020
AND ... "someboolean" = '-1' ...

This does not happen always, and I've seen it only in DELETE queries,
when I try to delete a row that has a checkbox that is checked (true).
The first try always works, the second try (deleting another row) it fails.

Now this is how it fails (IMHO):

The ResolveOneParam() function relies on the correct types being 
assigned to the parameters, In qb->ipdopts->parameters there is
SQLType and PGType. The SQLType is and enum that does not contain 
boolean, only the PGType can be boolean.

In PGAPI_Execute() (execute.c:1025) it calls prepareParameters, where
the PGTypes are found (don't know how exactly), and put into the stmt,
as stmt->ipd->ipdf.parameters.

If the PGTypes are not 0, the query runs fine. The second time
the query is executed, the query is already prepared (stmt->prepared=5)
and the prepare step is omitted. But then the PGTypes are missing,
the bool '-1' -> '1' conversion is not done and the query fails.

It turns out Access calls SQLFreeStmt(option=SQL_RESET_PARAMS),
that does SC_free_params, so the params get deleted.

But the params contain the result of the prepare call,
so IMHO the stmt->prepared state is now wrong, the transaction is no 
more prepared, so stmt->prepared should be reset to 0.

And that actually fixes the bug.

I hope this is useful, it took quite a while to track this down...

best regards,

	Oliver Freyd

diff --git a/statement.c b/statement.c
index da5abf5..a019d5d 100644
--- a/statement.c
+++ b/statement.c
 <at>  <at>  -581,6 +581,7  <at>  <at>  SC_free_params(StatementClass *self, char option)
  		APD_free_params(SC_get_APDF(self), option);
  		IPD_free_params(SC_get_IPDF(self), option);
+		if (self->prepared!=NOT_YET_PREPARED)\
SC_set_prepared(self, NOT_YET_PREPARED);
  	PDATA_free_params(SC_get_PDTI(self), option);
  	self->data_at_exec = -1;
Attachment (SC_free_params.patch): text/x-diff, 434 bytes


Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:
Bala krishna Devasani | 15 Oct 17:41 2014

PostgreSQL crash at SQLColAttribute()

Description: i am using postgresql database as a backend,connecting to postgres with unixodbc driver manager and libodbc++ library and psqlodbc driver. when i try to run my application to query some data it is getting crashed. It is getting crashed
at random functions.

i cannot exactly trace which function it is crashing.

it is crashing at three functions like

1.  SQLColAttribute
2.  SQLGetInfo

PostgreSQL version number you are running:

How you installed PostgreSQL:PostgreSQL 9.1 linux ubuntu

Changes made to the settings in the postgresql.conf file: No

Operating system and version:linux ubuntu 12.04 (64-bit)

What program you're using to connect to PostgreSQL:libodbc++-0.2.3 (libodbc++) library

PostgreSQL odbc driver : psqlodbc version(3.03)

ODBC using: unixODBC-2.3.2
For questions about any kind of error:

Description : i am trying to connect  my application to PostgreSQL. while i am trying run select query's it is getting crashed at certain functions.

i am using linux ubuntu (12.04) with unixODBC (2.3.2), PostgreSQL database (9.1), psqlodbc driver (3.03) , libodbc++-0.2.3

Thanks & Regards
Jade Koskela | 13 Oct 23:02 2014

crash bug on closed connection

I have been looking into this crash for a while now, and I finally have a good repro.

After digging through it with wireshark I observed this
client tries to send a query
 retransmit query
 retransmit query
client sends TCP [RST],[ACK]
Now it has crashed, so we restart it again and begin another connection successfully.

It seems that the connection has dropped, but the client was never informed, and it doesn't handle this gracefully. 

I reproed it like this:

On my mac running postgres server:
  Setup port forwarding to emulate a proxy or firewall problem
  ssh -L [public ip]:5433:localhost:5432 -N localhost

On my windows machine:
  Connect to port 5433 on my mac
  Run a query

On my mac:
  Kill the ssh proxy
  sighub postgres
  open the ssh proxy again

On my windows machine:
  Run another query (was never informed that the connection dropped)
  Crash in 

Inoue, Hiroshi | 10 Oct 02:16 2014

Re: Time for a new release?

(2014/10/07 16:48), Inoue, Hiroshi wrote:
> (2014/10/06 21:47), Heikki Linnakangas wrote:
>> There have been a lot of small fixes since the latest release. Time for
>> a new release?
> I have some changes in my local source and would push them in a day or two.

OK I pushed them.

As I mentioned before, I refined a bootstrapper project psqlodbc-setup.
Generated psqlodbc-setup.exe installes both 32bit and 64bit drivers.
Using psqlodbc-setup.exe is a recommended way now.

All drivers, MSIs and psqlodbc-setup.exe are generated by typing

    BuildAll.[ps1|bat] -A

Hiroshi Inoue

>> It would be nice to do a "final" 9.3 release pretty soon, so that we
>> could proceed with Michael Paquier's changes to remove support for < 7.4
>> servers. The plan was to go ahead with that in the first 9.4 release. If
>> we do the last 9.3 release now, we can do the first 9.4 release in a
>> month or so, at roughly the same time the community will likely release
>> server version 9.4.
>> - Heikki

I am using the free version of SPAMfighter.
SPAMfighter has removed 12722 of my spam emails to date.
Get the free SPAMfighter here:

Do you have a slow PC? Try a Free scan


Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

Cedric Berger | 3 Oct 14:52 2014

ODBC + Access not working for Foreign Table (FDW)


Having just tested my first FDW, I tried to access my foreign
tables with MS Access 2000 using the latest MS ODBC driver.

Unfortunately, I just found that foreign tables are not listed
when you do " Get External Data => Link Tables": Only Views
and Regular tables are shown.

I could workaround the problem by defining a view:

   CREATE VIEW workaround AS SELECT * FROM foreign_table.

But it sucks, and I don't know if there are performance drops
going through a view like that.

I glanced at the ODBC sources, and my guess is that inside
info.c, lines like:

     strcat(tables_query, " where relkind in ('r', 'v')");

should be modified to add the 'f' type.

Is that correct?
Could someone have a look at that?

right now, I can test a MSI, but I've never compiled ODBC myself.


Oliver Freyd | 2 Oct 17:57 2014

Strange issues with numeric type and an Access frontend


I'm working with a database system that is based on an Access frontend 
and a postgresql backend, connected via the psqlODBC driver.

That works quite nicely, but there are some problems.

We use updatable views extensively, because otherwise many forms would 
be very slow.

Some of these views have calculated columns.
We often use the type numeric for these, especially if the column is an 
amount of money.

Recently we saw a strange bug in these columns, the values would by 
shown multiplied by 1000 or 10000, depending on the precicion of the 
column (e.g. *1000 for a numeric(20,3)).

Strangely this happens only on some client computers, an only after 
doing something that triggers the bug, like clicking on a hyperlink in 
the access application.

As a work-around, I've converted the datatypes of these columns to 
double, and the bug disappears. But I also had to compile the psqlODBC 
driver for this to work, as we had other problems with double columns
due the precision problems reported by Jon Smith. Access would emit 
errors like 'someone else has changed this record' when one tries to 
update a record with a calculated column as double, because Access would 
try to compare all fields in a row to the previous values.
That would fail due to rounding errors, but Access takes it as if 
someone else has edited the data.

Anyway, now this seems to be fixed in commit 

Maybe the numeric bug has something todo with client locale,
because it looks like the decimal point is lost in the numbers,
I'm not quite sure how numeric is converted from the server to the 
client, but we run a german locale, so on the client we use a comma as 
decimal point. No idea why this sometimes fails. Maybe someone else has 
a hint where I could look further...

best regards,

Oliver Freyd

Access frontend (Access 2013 runtime)
postgresql  server 9.1.13
psqlODBC driver 09.03.0300-1 (now self-compiled commit
from 26 Sep 2014


Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

pieri70 | 30 Sep 10:35 2014

Win 7 x64 odbc call failed

Hello postgres odbc users
I'm in trouble using Access 2013 and postgresql server.
My new laptop is a windows 7 professional 64bit and I have microsoft office
I want to connect a postgresql 9.1.13 It's a Debian server with postgres

select version() get this answer
"PostgreSQL 9.1.13 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.7.2-5) 4.7.2, 64-bit"

I tried to install many version of postgres odbc drivers from the postgres
site both x64 and x32.
I can correctly create both user and system connection and if I tri to test
the connection I get an affermative result, connection as reported by the
odbc administrative tool is ok.

My problem arises from the microsoft office 2013.
If I try to open a previous created db (office 2003 mdb) or a new empty db
created on the 2013 version I can't connect to the postgres server, I get a
message saying "call failed" (chiamata non riuscita in Italian language).

How can I solve this problem (don't tell me to use openoffice or linux, I
wish, but my laptop is not my own laptop..)

Thanks everybody

View this message in context:
Sent from the PostgreSQL - odbc mailing list archive at


Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

Pavan | 25 Sep 12:42 2014

Some sql query got stuck in poll.


I have application running in multi-threaded architecture and application
updates DB from data in cache periodically . But unfortunately we are
getting some query got stuck in poll for indefinite time. This behavior is
happened some time with application but not any particular scenario. We can
not reproduce it always it's random issue. We have design to restart
application if it got stuck for more than specified time period. 

I have attached some back trace for query processing as below:


#0 0x00007ff6d6f11ff3 in poll () from /lib64/
#1 0x00007ff6d0f9e467 in SOCK_wait_for_ready (sock=0x162ba20, output=0,
retry_count=1) at socket.c:512
#2 0x00007ff6d0f9f5e1 in SOCK_get_next_byte (self=0x162ba20, peek=0) at
#3 0x00007ff6d0f9f6f3 in SOCK_get_id (self=0x162ba20) at socket.c:685
#4 0x00007ff6d0f79e59 in CC_send_query_append (self=0x1628230,
query=0x1635c30 "UPDATE call_stats SET Peeringid=1, Setup=0, Connect=0,
DroppedSetup=0, OutSetup=0, InInvite=0, InReInvite=0, In1xx=0, In2xx=0,
InRe2xx=0, In3xx=0, In4xx=0, In5xx=0, In6xx=0, InAck=0, InReAck=0,
InCanc"..., qi=0x0, flag=4, stmt=0x1632b40, appendq=<optimized out>) at
#5 0x00007ff6d0faa44e in SC_execute (self=0x1632b40) at statement.c:2003
#6 0x00007ff6d0f8951e in Exec_with_parameters_resolved (stmt=0x1632b40,
exec_end=0x7fff9f4488b8) at execute.c:511
#7 0x00007ff6d0f8a8ca in PGAPI_Execute (hstmt=0x1632b40, flag=<optimized
out>) at execute.c:1153
#8 0x00007ff6d0fb0a8c in SQLExecute (StatementHandle=0x1632b40) at
#9 0x00007ff6d819fb16 in SQLExecute (statement_handle=0x160bd30) at
#10 0x0000000000467ae6 in ODBCDbModify (dmltype=DB_UPDATE, sql=0xcee5f8,
tablename=0x5f8663 "call_stats", incols=0x7fff9f448b80, incolcount=32,
conditioncount=3, affectedrowcount=0x7fff9f448ec8, publish_evt=0) at
#11 0x0000000000468cb5 in ODBCDbUpdate (sql=<optimized out>,
tablename=<optimized out>, incols=<optimized out>, incolcount=<optimized
out>, conditions=<optimized out>,
conditioncount=<optimized out>, affectedrowcount=0x7fff9f448ec8,
publish_evt=0) at /usr/src/packages/iserver/server/x86_64/../db_mysql.c:908
#12 0x0000000000488547 in DSStoreEntry (publish_evt=0,
affectedrowcount=0x7fff9f448ec8, conditioncount=3, incolcount=32,
cols=0x7fff9f448b80, tablename=0x5f8663 "call_stats",
storesql=0xcee5f8) at
#13 DbStoreCallStatsEntry (db=<optimized out>, entry=<optimized out>,
skey=<optimized out>, skeylen=<optimized out>)
at /usr/src/packages/iserver/server/x86_64/../dbservice.c:15977
#14 0x0000000000457a7c in insertIntervalStats (intervalStat=0x15f4fe8,
instanceId=1, type=SEC, isUpdate=false) at ../sync_db.c:234
#15 0x00000000004559f9 in populateIntervalStats (destStat=<optimized out>,
origStat=<optimized out>, iter=60, type=SEC) at ../sync_utility.c:40
#16 0x0000000000453320 in callStatsHeapPopulate () at ../initializer.c:419
#17 0x000000000045502b in initInMemoryDS () at ../initializer.c:146
#18 0x000000000044f662 in main (argc=<optimized out>, argv=0x7fff9f4491c8)
at ../main.c:136


#0 0x00007f97d955eff3 in poll () from /lib64/
#1 0x00007f97d76ebec9 in SOCK_connect_to (self=0x1545970, port=<optimized
out>, hostname=<optimized out>, timeout=10) at socket.c:395
#2 0x00007f97d76c8df9 in original_CC_connect (self=0x157e580,
password_req=<optimized out>, salt_para=<optimized out>) at
#3 0x00007f97d76ca241 in CC_connect (self=0x157e580, password_req=0 '\000',
salt_para=0x7fff177ebec0 "") at connection.c:2022
#4 0x00007f97d76d49cc in PGAPI_DriverConnect (hdbc=0x157e580,
hwnd=<optimized out>, szConnStrIn=<optimized out>, cbConnStrIn=<optimized
out>, szConnStrOut=0x7fff177f0340 "",
cbConnStrOutMax=4096, pcbConnStrOut=0x7fff177f146e, fDriverCompletion=0) at
#5 0x00007f97d76fd6a0 in SQLDriverConnect (hdbc=0x157e580, hwnd=0x0,
szConnStrIn=0x8603ac "SERVERNAME=;DSN=msw;DATABASE=msw;UID=msw",
szConnStrOut=<optimized out>, cbConnStrOutMax=4096,
pcbConnStrOut=0x7fff177f146e, fDriverCompletion=0) at odbcapi.c:226
#6 0x00007f97daa0e755 in SQLDriverConnect (hdbc=0x157a5c0, hwnd=0x0,
conn_str_in=0x8603ac "SERVERNAME=;DSN=msw;DATABASE=msw;UID=msw",
conn_str_out=0x7fff177f0340 "", conn_str_out_max=4096,
ptr_conn_str_out=0x7fff177f146e, driver_completion=0) at
#7 0x0000000000459e1b in DetectMasterDbConnection (useslaveifnomaster=0) at
#8 0x0000000000457f09 in DbGetConnection (hdbc=0x7fff177f2580) at
#9 0x000000000045b02d in ODBCDbModify (dmltype=DB_INSERT, sql=0xc81b40,
tablename=0x5aa06c "call_stats", incols=0x7fff177f2650,
incolcount=<optimized out>, conditions=0x0,
conditioncount=0, affectedrowcount=0x7fff177f2998, publish_evt=0) at
#10 0x000000000045c002 in ODBCDbInsert (sql=<optimized out>,
tablename=<optimized out>, incols=<optimized out>, incolcount=<optimized
out>, affectedrowcount=<optimized out>,
publish_evt=<optimized out>) at
#11 0x0000000000478b44 in DSInsertEntry (publish_evt=0,
affectedrowcount=0x7fff177f2998, incolcount=35, cols=0x7fff177f2650,
tablename=0x5aa06c "call_stats", insertsql=0xc81b40)
at /d4/rel8.1/patches/8.1.2/
#12 DbInsertCallStatsEntry (db=<optimized out>, entry=<optimized out>,
skey=<optimized out>, skeylen=<optimized out>)
at /d4/rel8.1/patches/8.1.2/
#13 0x000000000044ce11 in insertIntervalStats (intervalStat=0x152e518,
instanceId=7, type=SEC, isUpdate=false) at ../sync_db.c:217
#14 0x000000000044b029 in populateIntervalStats (destStat=<optimized out>,
origStat=<optimized out>, iter=60, type=SEC) at ../sync_utility.c:40
#15 0x0000000000448d90 in callStatsHeapPopulate () at ../initializer.c:411
#16 0x000000000044a76b in initInMemoryDS () at ../initializer.c:140
#17 0x0000000000445611 in main (argc=<optimized out>, argv=0x7fff177f2c88)
at ../main.c:158


#0 0x00007fb2f0a23ff3 in poll () from /lib64/
#1 0x00007fb2eaab0467 in SOCK_wait_for_ready (sock=0x1645130, output=0,
retry_count=1) at socket.c:512
#2 0x00007fb2eaab15e1 in SOCK_get_next_byte (self=0x1645130, peek=0) at
#3 0x00007fb2eaab16f3 in SOCK_get_id (self=0x1645130) at socket.c:685
#4 0x00007fb2eaa8be59 in CC_send_query_append (self=0x1641940,
query=0x7fb2eaad4d2d "COMMIT", qi=0x0, flag=0, stmt=0x0, appendq=<optimized
out>) at connection.c:2805
#5 0x00007fb2eaa8d99b in CC_commit (self=0x1641940) at connection.c:512
#6 0x00007fb2eaa9cf95 in PGAPI_Transact (henv=0x0, hdbc=0x1641940, fType=0)
at execute.c:1221
#7 0x00007fb2eaac6dc5 in SQLEndTran (HandleType=<optimized out>,
Handle=0x1641940, CompletionType=0) at odbcapi30.c:176
#8 0x00007fb2f1cb0623 in SQLEndTran (handle_type=<optimized out>,
handle=0x164add0, completion_type=0) at SQLEndTran.c:486
#9 0x000000000046aef6 in ODBCDbModify (dmltype=DB_UPDATE, sql=0xd01f38,
tablename=0x607400 "call_stats", incols=0x7fff1862db80, incolcount=32,
conditions=0x7fff1862de80, conditioncount=3,
affectedrowcount=0x7fff1862dec8, publish_evt=0) at
#10 0x000000000046b6b5 in ODBCDbUpdate (sql=<optimized out>,
tablename=<optimized out>, incols=<optimized out>, incolcount=<optimized
conditions=<optimized out>, conditioncount=<optimized out>,
affectedrowcount=0x7fff1862dec8, publish_evt=0)
at /usr/src/packages/iserver/server/x86_64/../db_mysql.c:909
#11 0x000000000048c857 in DSStoreEntry (publish_evt=0,
affectedrowcount=0x7fff1862dec8, conditioncount=3, incolcount=32,
tablename=0x607400 "call_stats", storesql=0xd01f38) at
#12 DbStoreCallStatsEntry (db=<optimized out>, entry=<optimized out>,
skey=<optimized out>, skeylen=<optimized out>)
at /usr/src/packages/iserver/server/x86_64/../dbservice.c:16603
#13 0x000000000045a36c in insertIntervalStats (intervalStat=0x16129f0,
instanceId=42, type=MIN, isUpdate=false) at ../sync_db.c:229
#14 0x00000000004582f9 in populateIntervalStats (destStat=<optimized out>,
origStat=<optimized out>, iter=60, type=MIN) at ../sync_utility.c:40
#15 0x0000000000455c42 in callStatsHeapPopulate () at ../initializer.c:422
#16 0x000000000045792b in initInMemoryDS () at ../initializer.c:146
#17 0x0000000000451dd2 in main (argc=<optimized out>, argv=0x7fff1862e1c8)
at ../main.c:142


Please help me to identify root cause of this problem as this is coming with
different release of PostgresSQL-ODBC driver. 

View this message in context:
Sent from the PostgreSQL - odbc mailing list archive at


Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription: