Fix bug in SQLCancel().

If one thread was busy executing a savepoint statement, while another thread
calls SQLCancel() on the statement, SQLCancel() would try to release the
locks held by the other thread. That's extremely racy; if the other thread
tries to increment/decrement the lock_CC_for_rb counter at the same time,
we could end up releasing the lock to many times or too few times. Also,
releasing a pthread mutex from a different thread than the one who acquired
it is undefined behavior.

AFAICS the DiscardStatementSvp() call in SQLCancel() can be safely removed.
It's outright wrong and dangerous if the statement is busy executing in
a different thread, and the other codepaths in PGAPI_Cancel() already call
DiscardStatementSvp().

Bug report by Jade Koskela.
Refactor SQLCancel() and add comments, for readability.
Fix compilation on Windows, broken by my previous commit.

Michael Paquier
This patch fixes a NULL pointer dereference occurring when connecting
using SSPI authentication (without kerberos, a local Windows user trying
to connect to postgres instance on same host). Patch originally by
Nikhil R Deshpande, 1 line added for safety by me.
Remove unused function.

Previous commit added a void return to a function with char * return value,
which generated a warning. On further inspection, the whole function is
used nowhere, so just remove it rather than try fixing the warning.
Fix bug with UseDeclareFetch=1 when a transaction is committed before fetch.

If a server cursor is closed before the application has fetched any rows
from the result set, the "base" of the result set's cached rowset was
off-by-one.

Also add a regression test for the same.

This fixes the bug reported by Jan-Peter Seifert.
Fix driver name mismatch between 32-bit ODBC app and 64-bit MSDTC host

If the 32-bit driver runs on a 64-bit host within a 32-bit app
running under SysWow64 then XA transactions will fail to recover.

That's because recovery is done by pgxalib.dll which runs within
MSDTC.exe - a 64-bit application. It connects to a DSN supplied
by psqlODBC in EnlistInDtc_1pipe during DTC enlistment by the
XA resource manager. This DSN uses the driver name of the client's
ODBC driver - which is fine so long as the client and MSDTC
architectures match. If they don't then MSDTC will fail to connect
to Pg, so it'll never resolve transactions.

Traces of MSDTC will show RM_COMMIT_DELIVERY_FAILED_DUE_TO_CONNECTION_DOWN
events.

Traces of pgxalib.dll will show xa_recover(..) being entered, followed by
"SQLDriverConnect return=-1".

To fix this, we detect if we're running under SysWow64 by examining the
PROCESSOR_ARCHITEW6432 environment variable and supply the 64-bit driver name
if so.

See mailing list thread:

  http://www.postgresql.org/message-id/53A45B59.70303@2ndquadrant.com

for details.