ALTER TABLE ADD COLUMN exhibits a significant memory leak when adding a column with a default expression. In that situation, we need to rewrite the heap relation. To evaluate the new default expression, we use ExecEvalExpr(); however, this can allocate memory in the current memory context, and ATRewriteTable() does not switch out of the active portal's heap memory context. The end result is a rather large memory leak (on the order of gigabytes for a reasonably sized table). To repro, just create a large table (a few hundred megabytes), and add a serial column to it. This patch changes ATRewriteTable() to switch to the per-tuple memory context before beginning the per-tuple loop. It also removes an explicit heap_freetuple() in the loop, since that is no longer needed. In an unrelated change, I noticed the code was scanning through the attributes of the new tuple descriptor for each tuple of the old table. I changed this to use precomputation. Barring any objections, I will apply this to HEAD and REL8_0_STABLE tomorrow. -Neil
On Wed, 2005-02-09 at 15:56 +1100, Neil Conway wrote: > This patch changes ATRewriteTable() to switch to the per-tuple memory > context before beginning the per-tuple loop. [...] > Barring any objections, I will apply this to HEAD and REL8_0_STABLE > tomorrow. Applied. -Neil
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера