Re: Protocol de-synchronisation bug, bogus query sent

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