| From: | "Maurice Gittens" <mgittens(at)gits(dot)nl> |
|---|---|
| To: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>, "Peter T Mount" <psqlhack(at)maidast(dot)demon(dot)co(dot)uk> |
| Cc: | "PostgreSQL-development" <hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] Memory leaks for large objects |
| Date: | 1998-02-18 07:07:36 |
| Message-ID: | 009201bd3c3b$e57aa8c0$c6fb4fc1@caleb..gits.nl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas G. Lockhart | 1998-02-18 07:49:33 | Lost a function overloading capability? |
| Previous Message | Thomas G. Lockhart | 1998-02-18 06:54:18 | Re: [HACKERS] Memory leaks for large objects |