Dependency problems with 8.02.0100 (was Latest ODBC driver?)

Dependency problems with 8.02.0100 (was Latest ODBC driver?)

am 01.09.2006 18:25:18 von Mark Morgan Lloyd

Apologies for starting a new thread for this, due to the selfish reason that my
ML gateway isn't very good at handling long ones :-)

Dependency Walker v2.1 applied to psqlodbc*.dll drivers on NT4W SP6a machines as
previously discussed. Hope I've got this right.


On the machine with ODBC drivers 3.50.33.8 and psqlodbc*.dll 8.02.0100:
------------------------------------------------------------ -----------

psqlodbc30a.dll refers to xolehlp.dll (ordinal 5, no name) which is missing.

libpq.dll refers to krb5_32.dll, which in turn refers to secur32.dll
(LsaCallAuthenticationPackage, LsaConnectUntrusted,
LsaLookupAuthenticationPackage, LsaFreeReturnBuffer, LsaGetLogonSessionBuffer)
which is missing.

psqlodbc35w.dll seems to have the same missing dependencies.


On the machine with ODBC drivers 3.0.28.2 and psqlodbc*.dll 8.01.0200:
------------------------------------------------------------ ----------

There is no indication of a missing dependency on xolehlp.dll, despite the fact
that the file does not exist on this machine.

libpq.dll refers to krb5_32.dll, which in turn refers to secur32.dll with
functions missing as above. However this didn't appear to lead to a fatal error
so may be benign.



Applying Dependency Walker to the failing app shows it to be clean.

Checking psqlodbc.dll from 7.02 shows that its only direct dependencies are
kernel DLLs, i.e no reference to xolehlp.dll etc. Same for psqlodbc30.dll and
psqlodbc30w.dll.

Hope this helps.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Dependency problems with 8.02.0100 (was Latest ODBC

am 01.09.2006 21:10:48 von Dave Page

On 1/9/06 17:25, "Mark Morgan Lloyd"
wrote:

> Apologies for starting a new thread for this, due to the selfish reason that
> my
> ML gateway isn't very good at handling long ones :-)
>
> Dependency Walker v2.1 applied to psqlodbc*.dll drivers on NT4W SP6a machines
> as
> previously discussed. Hope I've got this right.
>
>
> On the machine with ODBC drivers 3.50.33.8 and psqlodbc*.dll 8.02.0100:
> ------------------------------------------------------------ -----------
>
> psqlodbc30a.dll refers to xolehlp.dll (ordinal 5, no name) which is missing.
>
> libpq.dll refers to krb5_32.dll, which in turn refers to secur32.dll
> (LsaCallAuthenticationPackage, LsaConnectUntrusted,
> LsaLookupAuthenticationPackage, LsaFreeReturnBuffer, LsaGetLogonSessionBuffer)
> which is missing.
>
> psqlodbc35w.dll seems to have the same missing dependencies.
>
secur32.dll is probably not an issue, but xolehlp.dll is part of MSDTC which
is what Hiroshi suspected the problem might be. Can you try updating your
08.02.0100 release with the DLLs from his page please, per his suggestion:

> I've suspected the MSDTC support. Though I'm not sure, delay loading of
> OLEHLP.dll may solve the problem.
> Please try the dlls at
> http://www.geocities.jp/inocchichichi/psqlodbc/index.html .

Thanks, Dave.


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Dependency problems with 8.02.0100 (was Latest ODBC driver?)

am 01.09.2006 23:10:13 von Mark Morgan Lloyd

> AAAAHHHHHH I SHOULDN'T HAVE DONE THAT...............

Well I think that localises the problem a bit :-)

The 8.01 driver defaults to preferring SSL, while 8.02 defaults to disabling it.

If 8.02 connects to the v7 or v8 servers with SSL disabled then the result is
the error dialogues and logs in the last message.

If 8.02 connects to the v7 server with SSL allowed it appears to progress past
the authentication but then sits there without memory usage exploding. I'll grab
a log in case it's significant.

If 8.02 connects to the v8 server with SSL allowed then as soon as I think
nothing's happening and turn away memory usage explodes. This time I caught it
before the system started thrashing and terminated the process from Task
Manager.

Those logs are pretty big. I'll send them as email, if anybody else wants a copy
please yell over the next hour.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Dependency problems with 8.02.0100 (was Latest ODBC driver?)

am 02.09.2006 02:41:55 von Hiroshi Inoue

Mark Morgan Lloyd wrote:
>> AAAAHHHHHH I SHOULDN'T HAVE DONE THAT...............
>>
>
> Well I think that localises the problem a bit :-)
>
> The 8.01 driver defaults to preferring SSL, while 8.02 defaults to disabling it.
>
> If 8.02 connects to the v7 or v8 servers with SSL disabled then the result is
> the error dialogues and logs in the last message.
>

I've changed the code a little and uploaded the snapshot dll.
Please retry the SSL disabled mode if you have time.

> If 8.02 connects to the v7 server with SSL allowed it appears to progress past
> the authentication but then sits there without memory usage exploding. I'll grab
> a log in case it's significant.
>
> If 8.02 connects to the v8 server with SSL allowed then as soon as I think
> nothing's happening and turn away memory usage explodes. This time I caught it
> before the system started thrashing and terminated the process from Task
> Manager.

I have no idea why the memory usage explode occurs.
Please try UseDeclarefetch mode first.

regards,
Hiroshi Inoue


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Dependency problems with 8.02.0100 (was Latest ODBC driver?)

am 02.09.2006 09:38:45 von Dave Page

-----Original Message-----
From: Mark Morgan Lloyd [mailto:markMLl.out@telemetry.co.uk]
Sent: Fri 9/1/2006 9:45 PM
Cc: Dave Page; inoue@tpf.co.jp
Subject: Re: [ODBC] Dependency problems with 8.02.0100 (was Latest ODBC dri=
ver?)
=20
> Done. Working on the test machine with ODBC 3.50, attempting to connect t=
o the
> v7 database gives me a dialogue "Unknown user name or password. Sending t=
he
> authentication packet failed; Could not flush the socket buffer." If I tr=
y to
> connect to the v8 database I get "Unknown user name or password. Unexpect=
ed
> protocol character=3D'; Socket has been closed."

Wierd. What protocol version do you have set in the driver options?

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Dependency problems with 8.02.0100 (was Latest ODBC driver?)

am 02.09.2006 11:45:03 von Mark Morgan Lloyd

Dave Page wrote:

> > Done. Working on the test machine with ODBC 3.50, attempting to connect to
> > the v7 database gives me a dialogue "Unknown user name or password. Sending
> > the authentication packet failed; Could not flush the socket buffer." If I
> > try to connect to the v8 database I get "Unknown user name or password.
> > Unexpected protocol character='; Socket has been closed."
>
> Wierd. What protocol version do you have set in the driver options?

On page 2 of the dialogue the protocol section is disabled but appears to be set
to 7.4.

I should of course have thought of that before testing against the old v7 server
:-)

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Dependency problems with 8.02.0100 (was Latest ODBC driver?)

am 02.09.2006 15:28:53 von Mark Morgan Lloyd

Hiroshi Inoue wrote:

> I've changed the code a little and uploaded the snapshot dll.
> Please retry the SSL disabled mode if you have time.

Spending time on this is rather more palatable than any of the alternatives,
most of which involve not being to upgrade the server (hence no replication)
until I've reworked the clients.

446464 Sep 2 09:25 psqlodbc30a.dll
1013 Sep 2 01:35 pgxalib.exp
2290 Sep 2 01:35 pgxalib.lib

Above copied to .../bin on the client.

With SSL disabled to the v7 server I get the same "Unknown user name [...] Cound
not flush socket buffer". Changing the protocol (which is now selectable again)
to 6.4+ and after about a minute I get "Read failure. No response from the
backend; No response from the backend.".

Switching to protocol 7.4+ talking to the v8 server, SSL disabled, the client
sits there indefinitely using 50-90% CPU but doesn't blow up.

> I have no idea why the memory usage explode occurs.
> Please try UseDeclarefetch mode first.

Appears to have no effect, but there again the memory isn't blowing up at the
moment.

I'll send a log for the server v8 failed session to you and Dave.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Dependency problems with 8.02.0100 (was Latest ODBC driver?)

am 02.09.2006 18:27:47 von Mark Morgan Lloyd

Mark Morgan Lloyd wrote:

> Changing the protocol (which is now selectable again) to 6.4+

The protocol is fixed at 7.4+ unless SSL is disabled.

The latest driver plus last night's DLL set to 6.4+ against the v7 server works
with one out of the three apps here, the other two time out. This is better than
the case with the v8.1 driver but to look at exactly what the clients are doing
I'm going to have to revert to the v7 driver.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly