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
Joe Maldonado and I have a vexing problem with PostgreSQL 7.4.5 (we are
using the PGDG RPMs on a RedHat 9 system). He posted about this briefly
with the subject "info on strange error messages on postgresql" on this
list, but I'll start from the beginning. About once per week the
database ent
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
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 this same behaviour discussed back in 6.5 archives in the thread with subject "[SQL]
16 matches
Mail list logo
