Re: Protocol de-synchronisation bug, bogus query sent - Mailing list pgsql-odbc

On 06/19/2014 12:25 PM, Inoue, Hiroshi wrote:
>
>
> The code seems for v0/v1 protocol. Though I don't remember well, the
> dance was probably because v0/v1 didn't have clear sync mechanism.
> I wonder why the code reached there. The flag beforeV2 is broken?

Hm, yes.

beforeV2 seems to be 1, somehow. But only on these "isolated"
connections established via the callstack:


CC_connect(...) with trimmed conninfo

+        dsn     ""
+        desc     ""
+        drivername     "{PostgreSQL ANSI}"
+        server     "LOCALHOST"
+        database     "XXXX"
+        username     "Administrator"
+        protocol     "7.4"
+        port     "5432"
+        sslmode     "disable"
+        conn_settings    {name=0x02e68fb0 "set search_path to
femsconfig_femsmqsv1601" }    pgNAME
        use_server_side_prepare    1 '\x1'    char
        lower_case_identifier    0 '\0'    char
        rollback_on_error    -1 'ÿ'    char
        force_abbrev_connstr    0 '\0'    char
        autocommit_public    1 '\x1'    char
        extra_opts    0    unsigned int
        xa_opt    1 '\x1'    char

PgDtc_connect(...)
IAsyncPG::getLockedXAConn()
IAsyncPG::RequestExec(...)  with CommitExec
DtcRequestExec(...)


that hit the problematic code in:

>      psqlodbc30a.dll!CC_send_query_append(ConnectionClass_ * self, const char * query, QueryInfo_ * qi, unsigned long
flag,StatementClass_ * stmt, const char * appendq) Line 3082    C 
>      psqlodbc30a.dll!SC_execute(StatementClass_ * self) Line 2092    C
>      psqlodbc30a.dll!Exec_with_parameters_resolved(StatementClass_ * stmt, int * exec_end) Line 511    C
>      psqlodbc30a.dll!PGAPI_Execute(void * hstmt, unsigned short flag) Line 1150    C
>      psqlodbc30a.dll!PGAPI_ExecDirect(void * hstmt, const unsigned char * szSqlStr, long cbSqlStr, unsigned short
flag)Line 195    C 
>>    psqlodbc30a.dll!CC_send_settings(ConnectionClass_ * self) Line 3794    C
>      psqlodbc30a.dll!CC_connect(ConnectionClass_ * self, char password_req, char * salt_para) Line 2187    C
>      psqlodbc30a.dll!PgDtc_connect(void * self) Line 4471    C
>      pgenlista.dll!IAsyncPG::getLockedXAConn() Line 597    C++
>      pgenlista.dll!IAsyncPG::RequestExec(unsigned long type, HRESULT res) Line 657    C++
>      pgenlista.dll!DtcRequestExec(void * para) Line 996    C++

The conninfo says it clearly _wants_ to use the V3 protocol. Hm. Maybe
the flag is not set up yet because the connection params are still being
sent? Nope, it's set at the top of CC_send_query_append.

However, the version is garbage:

        pg_version    0x02d08830 ""    char[128]
        pg_version_number    0.000000000    float
        pg_version_major    0    short
        pg_version_minor    0    short


Unsurprisingly, version 0 is not >= 7.4 .

So there's at least another bug here causing the version to be zero. It
looks like that's because the connection isn't established yet, per
connection.c:2187:


 /*
  * Since these functions allocate statements, and since the connection
  * is not established yet, it would violate odbc state transition
  * rules.  Therefore, these functions call the corresponding local
  * function instead.
  */
inolog("CC_send_settings\n");
  retsend = CC_send_settings(self);


and we're attempting to use the version obtained from the server before
we have it, instead of the conninfo-specified version to use for
protocol selection purposes.

A debug-mode assertion in the SERVER_VERSION_GT, SERVER_VERSION_GT and
SERVER_VERSION_EQ macros that bailed out if the version was 0 and it's
in the debug configuration would help, I think. Inclined to accept a
patch? If so, how does a newbie Windows programmer like me actually *do*
such an assertion in Windows-y code?



--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services