2006/1/4, John Goerzen <[EMAIL PROTECTED]>: > After looking at the code again, it's possible that it's because you're > never calling pqClear on the result set. So the results returned by > PostgreSQL linger in memory forever.
Right! This was a bug. It is fixed now. Thanks. > I did have memory issues with Sqlite3 as well, but a quick inspection > isn't finding an obvious culprit. > > I use ForeignPtrs everywhere in HDBC to try to make sure that nothing > like this happens, and also that The Right Thing happens if a database > handle gets garbage collected without being explicitly closed first. I prefer not to rely on ForeignPtrs. It isn't guaranteed that they will be run. Another problem is that the order in which finalizers are executed isn't specified. In this case the connection handle can be closed before the statement handle. The usage of raw pointers has the advantage that it is easier for the developer to see that there is a space leak. > There's a small C wrapper in each database driver to help ensure that > nothing ever gets finalized more than once. I am using something like this too. In HSQL each Connection and Statement has one field of type MVar Bool. The flag is True if the handle is closed. In the same time the MVar is used for thread synchronization. The difference is that the code is in Database.HSQL and is reused from all drivers. I saw that you are using unsafe foreign imports everywhere in Database.HDBC.PostgreSQL. The trouble with them is that all Haskell threads will be suspended during the call. Maybe this explains why you don't see the crash which you saw with HSQL. I still don't know where was the problem with HSQL. Cheers, Krasimir _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
