Thread

1. Re: [HACKERS] Memory leaks for large objects

   Maurice Gittens <mgittens@gits.nl> — 1998-02-18T07:07:36Z

   >
   >Does the large object I/O persist across transactions? If so, then storage
   would
   >need to be outside of the usual context, which is reset after every
   transaction.
   >Is there a place where the large object context could be freed, but is not
   at
   >the moment?
   >
   >                                                          - Tom
   
   
   Large object I/O does not persist across transactions in my case.
   But maybe there are applications which assume that it does. So
   "fixing" it might break things. How about some compile time flag
   which selects between the old behaviour and new behaviour?
   The old behaviour could be the default.
   
   (The new behaviour would simply avoid fiddling with MemoryContexts at all.)
   My current workaround is to reconnect to the database after some
   number of transactions.
   
   Regards,
     Maurice
   
   
   

2. Re: [HACKERS] Memory leaks for large objects

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-18T15:01:16Z

   > 
   > Large object I/O does not persist across transactions in my case.
   > But maybe there are applications which assume that it does. So
   > "fixing" it might break things. How about some compile time flag
   > which selects between the old behaviour and new behaviour?
   > The old behaviour could be the default.
   > 
   > (The new behaviour would simply avoid fiddling with MemoryContexts at all.)
   > My current workaround is to reconnect to the database after some
   > number of transactions.
   
   Large object have been broken for quite some time.  I say remove the
   memory context stuff and see what breaks.  Can't be worse than earlier
   releases, and if there is a problem, it will show up for us and we can
   issue a patch.
   
   -- 
   Bruce Momjian
   maillist@candle.pha.pa.us
   
   

3. Re: [HACKERS] Memory leaks for large objects

   Peter T Mount <psqlhack@maidast.demon.co.uk> — 1998-02-18T20:40:13Z

   On Wed, 18 Feb 1998, Maurice Gittens wrote:
   
   > > >Does the large object I/O persist across transactions? If so, then
   > storage would >need to be outside of the usual context, which is reset
   > after every transaction.  >Is there a place where the large object
   > context could be freed, but is not at >the moment?  > > - Tom
   
   > Large object I/O does not persist across transactions in my case.
   
   They do here when I've tried them.
   
   > But maybe there are applications which assume that it does. So
   > "fixing" it might break things. How about some compile time flag
   > which selects between the old behaviour and new behaviour?
   > The old behaviour could be the default.
   > 
   > (The new behaviour would simply avoid fiddling with MemoryContexts at all.)
   > My current workaround is to reconnect to the database after some
   > number of transactions.
   
   At the moment, JDBC defaults to not using transactions. As not many
   java apps are using large objects yet (its a new 6.3 feature), it
   shouldn't be difficult to disable the API's if autoCommit is enabled (aka
   no transaction).
   
   Thinking about it, the large object examples in the source tree use
   transactions, so perhaps this is the original behaviour...
   
   -- 
   Peter T Mount  petermount@earthling.net or pmount@maidast.demon.co.uk
   Main Homepage: http://www.demon.co.uk/finder
   Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk