From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Gold <jgold(at)mazunetworks(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, Joe Maldonado <joe(at)mazunetworks(dot)com> |
Subject: | Re: Postmaster Out of Memory |
Date: | 2005-06-24 21:33:12 |
Message-ID: | 15786.1119648792@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I wrote:
> I think we have a suspect --- will go look.
Jeff, are you doing CLUSTER operations too?
Some preliminary testing says that:
7.4:
CLUSTER leaks a pg_temp_nnn relcache entry per call; if table
has toast subtable it also leaks a pg_toast_nnn_index entry per call
TRUNCATE on a table with toast leaks a pg_toast_nnn_index entry per call
8.0:
CLUSTER on a table with toast leaks a pg_toast_nnn_index entry per call
Since you showed both pg_temp_nnn and pg_toast_nnn_index items in your
dump, I surmise that there must be a fair number of CLUSTERs going on.
This is probably all actually just one bug --- 7.4's TRUNCATE used the
CLUSTER mechanism while 8.0 doesn't, so that explains why TRUNCATE isn't
showing a leak anymore. CLUSTER got whacked around too, but it looks
like we only cured half the leak :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-24 21:45:20 | Re: startup time |
Previous Message | Alvaro Herrera | 2005-06-24 20:17:41 | Re: Postgres 8.0 windows processes, field testing, and |