Re: [HACKERS] Problems w/ LO

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: [HACKERS] Problems w/ LO
Дата
Msg-id 199906011449.XAA00906@ext16.sra.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Problems w/ LO  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] pg_dump
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] ALTER TABLE ADD COLUMN