Jeff Gold <jgold@mazunetworks.com> writes:
>> I was sort of expecting you to come back and say that you
>> thought the process might have done 640K TRUNCATEs over its lifespan,
>> but I guess not?
> That's possible. The process does twelve TRUNCATEs every minute. The
> problem we're talking about seems to occur only when the system has been
> running for quite some time. Still, that's seems like an awefully slow
> rate. Is it really likely that a postmaster backend would accumulate
> relcache entries in this case?
Well, assuming that TRUNCATE is in fact causing a relcache entry to get
leaked, it's a kilobyte-and-change per entry ... so 12K per minute,
17M or so per day, you'd get to 640000 entries in about 37 days.
> What stands out is that nearly all of the entries seem to be pg_*
> tables. A "grep '^pg_' crash_dump | wc -l" gives 640499 entries, which
> is pretty nearly the entire file. We are careful not to name our tables
> with the "pg_" prefix, so I believe these are system tables. This is
> part of what originally made us believe pg_autovacuum was responsible.
I am not completely sure without looking at the code, but I think
TRUNCATE makes a short-lived table by the name of pg_temp_xxx, so
this observation seems to fit with the idea that TRUNCATE's at fault.
You showed some pg_toast entries in your original list, too, but those
could be subsidiaries of the truncated tables.
I think we have a suspect --- will go look.
regards, tom lane