Thread: Driver crashing on many temporary tables?
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. Operationson temporary tables seem to be involved every time. We store search results in dynamically generated temporarytables and the problematic operations create(d) MANY of them in recursive functions. We restored the test dbs fromthe 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'srelease 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 tochange 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 fromnormal. 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 -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
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 considerablyfrom 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
Hello Hiroshi Inoue, thank you very much for your quick reply. > > 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. Well - It might just be a flaw in our code/design that is eating resources away unnecessarily. It's just strange that it'sthe 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 doesnot crash on this db. I noticed that quite a few cursors are declared with hold (but also released) during the run ofthe problematic application. The encoding of the data bases is LATIN1. Yesterday I detected lines with characters not definedin 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'll send the login information to your private emailaddress as soon as I get it or do you maybe have a ftp server where I can upload the logs? If psqlodbc-08_00_0101 isnot crashing should I try to let the run be logged in Mylog and Comlog? Thank you very much, Peter -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Hello, I did some more checks. psqlodbc-08_00_0101 is indeed not crashing - psqlodbc-08_01_0200 does. I haven't tested the otherversions in between yet. Maybe the switch to libpq and ANSI/Unicode versions does make the difference. Via script I'vefound some tuples with characters not defined in LATIN1 - the db's encoding. I've replaced all the characters in questionand 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 Statement ( via SQL statement in the connect settings forexample?) in older versions of psqlODBC (those without radio button)? Otherwise errors not connected to this problem couldoccur. Can I change the path to the psqlODBC Logs from C:\? > > 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. > 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 -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01