Driver crashing on many temporary tables?

Hello,

we have a problem with psqlODBC v8.2.300 (maybe some older releases as we=
ll) and above - up to v8.3.400.
Some large operations/transactions can cause the driver to crash - obviou=
sly depends on the size of the db as well though. It seems to happen on t=
he same query on the same client - but different from the other clients/s=
ervers/days. Operations on temporary tables seem to be involved every tim=
e. We store search results in dynamically generated temporary tables and =
the problematic operations create(d) MANY of them in recursive functions.=
We restored the test dbs from the same backup.
The servers (e.g. Windows v8.3.6 and Linux v8.3.5) don't crash though.
Remarkably older versions like v8.0.01.01 have been reported to now show =
this problem with the same db. I did check the psqlODBC's release notes b=
ut I have no idea which change could indirectly be resonsible.
I activated Mylog and Comlog in the system-DSN. The Uncompressed Mylog go=
t pretty large (over 2,5 GB) so is there a way to change the standard pat=
hs for these logs?
It seems that Mylog uses quite a few resources as well - e.g. I had to in=
crease max_locks_per_transaction considerably from normal. Otherwise our =
application would hang in transaction.
The compressed log-Files are still over 250 MB - so I didn't attach them.
Do I just have to increase other server/psqlODBC parameters to get rid of=
the crash?

Thank you very much in advance,

Peter


--=20
Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=3DOM.AD.PD003K11308T456=
9a

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Driver crashing on many temporary tables?

Hi,

Jan-Peter Seifert wrote:
> Hello,
>
> we have a problem with psqlODBC v8.2.300 (maybe some older releases as well) and above - up to v8.3.400.
> Some large operations/transactions can cause the driver to crash - obviously depends on the size of the db as well though.
> It seems to happen on the same query on the same client - but
different from the other clients/servers/days.
> Operations on temporary tables seem to be involved every time. We
store search results in dynamically generated temporary
> tables and the problematic operations create(d) MANY of them in
recursive functions. We restored the test dbs from the same
> backup.
> The servers (e.g. Windows v8.3.6 and Linux v8.3.5) don't crash though.
> Remarkably older versions like v8.0.01.01 have been reported to now show this problem with the same db. I did check the
> psqlODBC's release notes but I have no idea which change could
indirectly be resonsible.
> I activated Mylog and Comlog in the system-DSN. The Uncompressed Mylog got pretty large (over 2,5 GB) so is there a way
> to change the standard paths for these logs?
> It seems that Mylog uses quite a few resources as well - e.g. I had to increase max_locks_per_transaction considerably from normal. Otherwise our application would hang in transaction.
> The compressed log-Files are still over 250 MB - so I didn't attach them.

Hmm I'm not sure I can find something from such a big file.
BTW how big is the size of Commlog file?
Anyway could you put them somewhere where I can dounload it?

regards,
Hiroshi Inoue


--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Driver crashing on many temporary tables?

Hello Hiroshi Inoue,

thank you very much for your quick reply.

> > we have a problem with psqlODBC v8.2.300 (maybe some older releases a=
s
> well) and above - up to v8.3.400.
> > Some large operations/transactions can cause the driver to crash -
> obviously depends on the size of the db as well though.
> > It seems to happen on the same query on the same client - but=20
> different from the other clients/servers/days.
> > Operations on temporary tables seem to be involved every time. We=20
> store search results in dynamically generated temporary
> > tables and the problematic operations create(d) MANY of them in=20
> recursive functions. We restored the test dbs from the same
> > backup.
> > The servers (e.g. Windows v8.3.6 and Linux v8.3.5) don't crash though=
..
> > Remarkably older versions like v8.0.01.01 have been reported to now s=
how
> this problem with the same db. I did check the
> > psqlODBC's release notes but I have no idea which change could=20
> indirectly be resonsible.
> > I activated Mylog and Comlog in the system-DSN. The Uncompressed Mylo=
g
> got pretty large (over 2,5 GB) so is there a way
> > to change the standard paths for these logs?
> > It seems that Mylog uses quite a few resources as well - e.g. I had t=
o
> increase max_locks_per_transaction considerably from normal. Otherwise =
our
> application would hang in transaction.
> > The compressed log-Files are still over 250 MB - so I didn't attach
> them.
>=20
> Hmm I'm not sure I can find something from such a big file.

Well - It might just be a flaw in our code/design that is eating resource=
s away unnecessarily. It's just strange that it's the driver and not the =
server crashing and that older versions of psqlODBC seem to work fine.

> BTW how big is the size of Commlog file?

The Commlog is about 70 MB. I'll do another run with psqlodbc-08_00_0101 =
myself to make sure that this version really does not crash on this db. I=
noticed that quite a few cursors are declared with hold (but also releas=
ed) during the run of the problematic application. The encoding of the da=
ta bases is LATIN1. Yesterday I detected lines with characters not define=
d in LATIN1 in the dump. I'll check on this as well.

> Anyway could you put them somewhere where I can dounload it?

I've asked our admins to set up an account on our ftp server for you. I'l=
l send the login information to your private email address as soon as I g=
et it or do you maybe have a ftp server where I can upload the logs? If p=
sqlodbc-08_00_0101 is not crashing should I try to let the run be logged =
in Mylog and Comlog?

Thank you very much,

Peter
--=20
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen=
: http://www.gmx.net/de/go/multimessenger01

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Re: Driver crashing on many temporary tables?

Hello,

I did some more checks. psqlodbc-08_00_0101 is indeed not crashing - psql=
odbc-08_01_0200 does. I haven't tested the other versions in between yet.=
Maybe the switch to libpq and ANSI/Unicode versions does make the differ=
ence. Via script I've found some tuples with characters not defined in LA=
TIN1 - the db's encoding. I've replaced all the characters in question an=
d will run another test with the newest psqlODBC on the db.

BTW is there a way to manually set the ROLLBACK LEVEL ON ERROR to Stateme=
nt ( via SQL statement in the connect settings for example?) in older ver=
sions of psqlODBC (those without radio button)? Otherwise errors not conn=
ected to this problem could occur.

Can I change the path to the psqlODBC Logs from C:\?

> > we have a problem with psqlODBC v8.2.300 (maybe some older releases a=
s
> well) and above - up to v8.3.400.
> > Some large operations/transactions can cause the driver to crash -
> obviously depends on the size of the db as well though.
> > It seems to happen on the same query on the same client - but=20
> different from the other clients/servers/days.
> > Operations on temporary tables seem to be involved every time. We=20
> store search results in dynamically generated temporary
> > tables and the problematic operations create(d) MANY of them in=20
> recursive functions. We restored the test dbs from the same
> > backup.
> > The servers (e.g. Windows v8.3.6 and Linux v8.3.5) don't crash though=
..
> > Remarkably older versions like v8.0.01.01 have been reported to now s=
how
> this problem with the same db. I did check the
> > psqlODBC's release notes but I have no idea which change could=20
> indirectly be resonsible.
> > I activated Mylog and Comlog in the system-DSN. The Uncompressed Mylo=
g
> got pretty large (over 2,5 GB) so is there a way
> > to change the standard paths for these logs?
> > It seems that Mylog uses quite a few resources as well - e.g. I had t=
o
> increase max_locks_per_transaction considerably from normal. Otherwise =
our
> application would hang in transaction.

> > The compressed log-Files are still over 250 MB - so I didn't attach
> them.

> Anyway could you put them somewhere where I can dounload it?

I've sent a private mail with the download information.

Thank you very much,

Peter
--=20
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen=
: http://www.gmx.net/de/go/multimessenger01

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc