Re: msdtc with 32-bit app fails to resolve in-doubt or not-notifed transactions - Mailing list pgsql-odbc

(2014/06/21 1:03), Craig Ringer wrote:
> Hi folks
>
> I've found an issue with psqlODBC's MSDTC support and pgxalib.dll, where
> a 32-bit application on a 64-bit server will intermittently leave
> transactions in the "only failed to notify" state in MSDTC.
>
> This occurs when:
>
> - The application exits normally after its final ITransaction::Commit
> call returns but before MSDTC has invoked
> ITransactionResourceAsync::CommitRequest on the psqlODBC-provided
> IAsyncPG object; or
>
> - When the application or server crash after MSDTC Phase I but before
> Phase II.
>
> In both these cases the resource manager is supposed to handle
> transaction resolution. It uses pgxalib.dll for this as that's the
> registered XA co-ordinator for the resource type.
>
> I've been able to trace pgxalib.dll (which, btw, was painful, will
> follow up on that) and found that XAConnection::xa_recover() is being
> called on the transaction, as expected. It's calling into
> XAConnection::ActivateConnection, where it fails to establish an ODBC
> connection and bails out at the test at 142 after getting return code -1
> from SQLDriverConnect(...).
>
> http://msdn.microsoft.com/en-us/library/ms716219(v=vs.85).aspx
>
> suggests that this is SQL_ERROR. pgxalib.dll doesn't call SQLGetDiagRec
> or SQLGetDiagField to get any details and log them; I'll submit a
> separate patch for that.
>
> It took me a while to figure it out, but SQLDriverConnect is failing
> because it's using the name of the 32-bit driver,

Oops, it's my mistake. It may be better to rewrite the code completely
using libpq APIs instead of ODBC APIs.

> since it got the DSN
> from a 32-bit application. So there's no such driver as far as the
> 64-bit application is concerned.
>
> (It didn't help that I couldn't enable system-wide ODBC tracing on the
> system for unrelated and annoying as-yet-unresolved reasons with the
> ODBC driver manager).
>
> Anyway - it looks like it'll be necessary to figure out in pgxalib.dll
> when this is happening and remap the driver name. That seems pretty
> crude, though, so I'm looking for better ideas.
>
> I'll follow up when it's not midnight with:
>
> - a patch to add proper error diagnostics in pgxalib.dll on connection
> failure;
>
> - results of testing a hack that just mangles the dsn connection string
> manually, as a proof of concept to show that this is really the issue; and
>
> - If I can figure out how to do it the right way (as opposed to just
> abusing a breakpoint to set the lvalue on return like I ended up doing),
> some documentation on how to turn pgxalib tracing on.
>
>
> As part of this I've been wondering whether it's possible to deal with
> that exit race condition. I'm not sure how to tackle that - I don't
> speak fluent COM or OLE. Do you think it'd be legal to delay in the
> IAsyncPG dtor until either we confirm commit of an a tx we know is in
> flight or we hit a (short) timeout?
>