Re: pg_dump on older version of postgres eating huge

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Krall <swalker(at)iglou(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_dump on older version of postgres eating huge
Date: 2004-03-19 23:55:55
Message-ID: 2360.1079740555@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Steve Krall <swalker(at)iglou(dot)com> writes:
> [root(at)r-and-d /tmp]# strings core | grep "DROP TRIGGER" | wc -l
> 5450219

> We have alot of triggers, but not 5.5 million :)

Looks like a smoking gun to me ...

Armed with that, I went back to the 7.1 source code, and what I see is a
huge (like O(N^2) in the number of triggers) leak in this routine. What
it needs is a "resetPQExpBuffer(delqry);" call somewhere in the loop
over triggers. I'd suggest putting it right before the line

appendPQExpBuffer(delqry, "DROP TRIGGER %s ", fmtId(tgname, force_quotes));

I see the same leak in 7.2, btw, but it's gone in 7.3. Didn't look at
prior releases ...

(It seems the reason no one noticed is that the constructed string isn't
actually *used* anyplace. Sigh.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ed L. 2004-03-20 01:08:28 Slow query not using index
Previous Message Greg Stark 2004-03-19 23:52:10 A way to refer to the "outer" query implicitly?