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).
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, which should slightly speed up
Thanks to steve(at)deefs(dot)net for reporting the leak.
tablecmds.c (r18.104.22.168 -> r22.214.171.124)
pgsql-committers by date
|Next:||From: User Tfavier||Date: 2005-02-09 23:38:41|
|Subject: pqa - pqa: Added WARNING/FATAL/PANIC errors Those are now taken into |
|Previous:||From: Neil Conway||Date: 2005-02-09 23:17:33|
|Subject: pgsql: ALTER TABLE ADD COLUMN exhibits a significant memory leak when |