Thread: memory leak in ALTER TABLE

memory leak in ALTER TABLE

From
Neil Conway
Date:
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


Attachment

Re: memory leak in ALTER TABLE

From
Neil Conway
Date:
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