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 по дате отправления: