SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-17-2008, 11:02 PM
| ||||
| ||||
 memory leak in ALTER TABLE 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org      |
|
04-17-2008, 11:02 PM
| ||||
| ||||
| Re: memory leak in ALTER TABLE 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
Linear Mode
