diff options
author | Neil Conway <neilc@samurai.com> | 2005-02-09 23:17:26 +0000 |
---|---|---|
committer | Neil Conway <neilc@samurai.com> | 2005-02-09 23:17:26 +0000 |
commit | 3df9abd1a5e90b4d32137065373cbb82e64e865c (patch) | |
tree | b90c598af7e2f1f55ae7b69c6f7780a80aa63a3d /src/backend/utils/adt/float.c | |
parent | d32b3aec52ed2284b7547927a161de0ca2c2ea72 (diff) | |
download | postgresql-3df9abd1a5e90b4d32137065373cbb82e64e865c.tar.gz postgresql-3df9abd1a5e90b4d32137065373cbb82e64e865c.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/utils/adt/float.c')
0 files changed, 0 insertions, 0 deletions