From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | t-ishii(at)sra(dot)co(dot)jp, "hackers(at)postgreSQL(dot)org" <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Problems w/ LO |
Date: | 1999-06-01 14:49:30 |
Message-ID: | 199906011449.XAA00906@ext16.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Then why should we use the private memory context if all lo operations
> > must be in a transaction?
>
> Right now, we could dispense with the private context. But I think
> it's best to leave it there for future flexibility. For example, I was
> thinking about flushing the context only if no LOs remain open (easily
> checked since lo_commit scans the cookies array anyway); that would
> allow cross-transaction LO handles without imposing a permanent memory
> leak. The trouble with that --- and this is a bug that was there anyway
> --- is that you need some way of cleaning up LO handles that are opened
> during an aborted transaction. They might be pointing at an LO relation
> that doesn't exist anymore. (And even if it does, the semantics of xact
> abort are supposed to be that all side effects are undone; opening an LO
> handle would be such a side effect.)
>
> As things now stand, LO handles are always closed at end of transaction
> regardless of whether it was commit or abort, so there is no bug.
>
> We could think about someday adding the bookkeeping needed to keep track
> of LO handles opened during the current xact versus ones already open,
> and thereby allow them to live across xact boundaries without risking
> the bug. But that'd be a New Feature so it's not getting done for 6.5.
Now I understand your point. Thank you for your detailed explanations!
---
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-06-01 15:15:27 | Re: [HACKERS] LIMITS |
Previous Message | Bruce Momjian | 1999-06-01 14:46:32 | Re: [HACKERS] Release date and docs |