Re: [HACKERS] temp table oddness?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] temp table oddness? |
Дата | |
Msg-id | 199909041626.MAA22163@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] temp table oddness? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] temp table oddness?
|
Список | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Yep. Wouldn't the best way be to have the temp system record the > > transaction id used, and to invalidate all temp entries associated with > > an aborted transaction. That is how the cache code works, so it seems > > it should be extended to the temp code. > > Yeah, that would work -- add an xact abort cleanup routine that goes > through the temprel list and removes entries added during the current > transaction. > > AFAICS this only explains the coredump-at-exit business, though. > I'm particularly baffled by that > ERROR: cannot find attribute 1 of relation pg_temp.24335.3 > in my last example --- do you understand why that's happening? Who knows. Once it gets messed up, anything can happen. The problem with indexes created in the same transaction as the temp table still is a problem, though you say your new cache code fixes that. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: