Re: [HACKERS] Problems w/ LO

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

Browse pgsql-hackers by date

  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