Re: pg_dump on older version of postgres eating huge - Mailing list pgsql-general

From Steve Krall
Subject Re: pg_dump on older version of postgres eating huge
Date
Msg-id Pine.LNX.4.58.0403200000240.30208@localhost.localdomain
Whole thread Raw
In response to Re: pg_dump on older version of postgres eating huge  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
I added the line, at the place you suggested.  pg_dump now works as
expected.

Thank you for taking the time to debug this!

Steve

On Fri, 19 Mar 2004, Tom Lane wrote:

> Steve Krall <swalker@iglou.com> writes:
> > [root@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
>

pgsql-general by date:

Previous
From: Joe Conway
Date:
Subject: Re: Index selection (and partial index) for BYTEA field
Next
From: Max Ahston
Date:
Subject: Re: Q: How do I return differnt rows depending on values