aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeSort.c
diff options
context:
space:
mode:
authorNeil Conway <neilc@samurai.com>2005-02-09 23:27:24 +0000
committerNeil Conway <neilc@samurai.com>2005-02-09 23:27:24 +0000
commit789aafebd5f36104afb8c02237fbe51c773d946e (patch)
tree47f47e40e843261d0e699d68fd125d9cb38d1bf3 /src/backend/executor/nodeSort.c
parentef006ded8e8e51423c7d9c9cb0d6c2576093df8c (diff)
downloadpostgresql-789aafebd5f36104afb8c02237fbe51c773d946e.tar.gz
postgresql-789aafebd5f36104afb8c02237fbe51c773d946e.zip
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 the loop. Thanks to steve@deefs.net for reporting the leak.
Diffstat (limited to 'src/backend/executor/nodeSort.c')
0 files changed, 0 insertions, 0 deletions