Re: [HACKERS] temp table oddness?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] temp table oddness? |
Дата | |
Msg-id | 5124.936484396@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] temp table oddness? (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] temp table oddness?u
|
Список | pgsql-hackers |
OK, I think that set of issues is solved. All the temp-table examples Tatsuo and I gave this morning work with the current sources, and I think shared invalidation of relcache entries is pretty solid too. What we have at this point is a set of tightly interwoven changes in relcache.c, temprel.c, sinval.c, and the syscache stuff. If we want to commit these changes into 6.5.*, it's all-or-nothing; I don't think we can extract just part of the changes. I'm real hesitant to do that. These are good fixes, I believe, but I don't yet trust 'em enough to put into a stable release. Can we live with the temp table misbehaviors as "known bugs" for 6.5.* ? The other thing we'd have to do if we don't back-patch these changes is remove the FileUnlink call in mdtruncate() in REL6_5, which would mean vacuum still won't remove excess segment files in 6.5.*. It would truncate 'em to zero length, though, so the deficiency isn't horrible AFAICS. My inclination is to do that, and leave the other problems as unfixed bugs for REL6_5. The alternative would be to back-patch all these changes and delay 6.5.2 release for a while while people beta-test. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: