(2014/06/23 10:23), Craig Ringer wrote:
> On 06/23/2014 08:34 AM, Inoue, Hiroshi wrote:
>> (2014/06/21 17:02), Craig Ringer wrote:
>>> On 06/21/2014 12:52 PM, Craig Ringer wrote:
>>>>
>>>>> Oops, it's my mistake. It may be better to rewrite the code completely
>>>>> using libpq APIs instead of ODBC APIs.
>>>>
>>>> I don't know if that'll work.
>>
>> The driver doesn't pass original connection strings to XARMCreate().
>> It seems possible to pass LIBPQ connection strings.
>
> Ah, I misunderstood that then.
>
> Great, that makes life easier.
>
>>> If the DSN is using SSPI, MSDTC.exe probably won't be able to
>>> authenticate to the DB as them. Same with any other kind of connection
>>> that depends on the properties of the current user account.
>>
>> Yes it's a severe problem.
>> I'll try to check the good way to do it.
>
> Thanks for thinking about it.
>
>>> Where possible I'd like to find ways to produce useful errors though,
>>> preferably at transaction enlistment time rather than commit phase II.
>>> Suggestions would be valued.
>>
>> It's possible to reject transaction enlistments at XARMCreate() though
>> I'm not sure if it's possible to tell the cause clearly to users.
>
> That'll be handy. As for telling users, we can always emit a message to
> the Windows Event Log. Competent admins should be looking there anyway.
>
> However, AFAIK we have no way to find out in advance if a connstring or
> DSN passed by the driver to msdtc for use in pgxalib will actually be
> usable
XARMCreate() triggers xa_open() ( and xa_close()) probably so as to
check that the XADLL works. Currently xa_open() doesn't connect to
the database and simply saves the connection information for subsequent
xa_commit(), xa_rollback() or xa_recover() call. When original process
finished COMMIT/ROLLBACK PREPARED properly, No database access occurs
in msdtc process. We can change xa_open() so that it connects to the
database immediately and causes an error to XARMCreate() when the
connection fails.
regards,
Hiroshi Inoue
> - in particular we have no way to query `pg_hba.conf` to see (a)
> how our current connection was authenticated and (b) whether the same
> connection settings would apply for the pgxalib connection. For example,
> I don't think there's any way to tell if our current user/host/db combo
> has a special cased 'trust' entry in pg_hba.conf that means other combos
> will require a password.