Jeff Gold <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> TRUNCATE and CLUSTER both rebuild indexes, so they'd also trigger the
>> leak.
> Sorry to bug you again, but I have two quick followup questions: (1) is
> the leak you discovered fixed on the 8.0 branch? and (2) would closing
> the datab
Tom Lane wrote:
TRUNCATE and CLUSTER both rebuild indexes, so they'd also trigger the
leak.
Sorry to bug you again, but I have two quick followup questions: (1) is
the leak you discovered fixed on the 8.0 branch? and (2) would closing
the database connection once per day be a reasonable way t
Tom Lane wrote:
Found it --- the actual leak is in index_create, not in TRUNCATE or
CLUSTER at all; and it's been there a really long time.
Patch for 7.4 branch attached.
Excellent! Does index_create refer to something that is invoked as a
consequence of CREATE INDEX? I'm looking through the
Jeff Gold <[EMAIL PROTECTED]> writes:
> Excellent! Does index_create refer to something that is invoked as a
> consequence of CREATE INDEX? I'm looking through the code on our side
> and can't find any obvious places where we recreate indexes, but I might
> just be missing something.
TRUNCATE
Jeff Gold <[EMAIL PROTECTED]> writes:
> [ backend memory leak ]
Found it --- the actual leak is in index_create, not in TRUNCATE or
CLUSTER at all; and it's been there a really long time.
Patch for 7.4 branch attached.
regards, tom lane
Index: index.c
Tom Lane wrote:
I suppose what we are looking at here is some operation that is
invalidating a relcache entry but failing to clear it.
Hm. After discussing this with people here we have a hypothesis. The
process that issues the TRUNCATE command does something a little
peculiar: every minute
Tom Lane wrote:
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 syste
Tom Lane wrote:
I can absolutely, positively say that that dump is not from the parent
postmaster. It's a backend.
That makes sense. I'm still a bit puzzled about why new clients can't
connect when the problem happens, though. Does the parent postmaster
need some resource from one of the b
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 wit
Jeff Gold <[EMAIL PROTECTED]> 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 se
Jeff Gold <[EMAIL PROTECTED]> writes:
> Hm. After discussing this with people here we have a hypothesis. The
> process that issues the TRUNCATE command does something a little
> peculiar: every minute or so twelve distinct functions are overwritten
> using CREATE OR REPLACE FUNCTION. Perhaps
Jeff Gold <[EMAIL PROTECTED]> writes:
> I presented the start and the end of what seemed to my uninformed eye to
> be the relevant error messages, since posting all 46.7 megabytes seemed
> impolite. :-) According to grep there are 122034 lines that include
> the word "index" in any combination
Jeff Gold <[EMAIL PROTECTED]> writes:
> About once per week the
> database enters some pathological state where the parent postmaster --
> NOT one of the child connections -- appears to run out of memory.
I can absolutely, positively say that that dump is not from the parent
postmaster. It's a
On Fri, Feb 27, 2004 at 01:45:07PM -0500, Joe Maldonado wrote:
> Hello all!
>
> when asking postgres to aggregate totals accross 4.5 or so Million
> records. The visible effect is that the postmaster will grow to the
> 3GB process limit and die without a core :(.
> I have seen
14 matches
Mail list logo
