From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) |
Cc: | phd2(at)earthling(dot)net, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Date: | 1999-02-08 16:43:45 |
Message-ID: | m109tmj-000EBRC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> Oleg Broytmann <phd(at)sun(dot)med(dot)ru> writes:
> > Hello!
> > A week ago I reported a problem with VACUUM ANALYZE on linux and memory
> > error. Three good guys saw my database and two of them for VACUUM problem,
> > I hope (Tom Lane and Thomas Lockhart).
> > Have you reproduced the case?
>
> Oh! I'm sorry, I thought I saw a report that someone had already fixed
> the problem, so I didn't look at it.
Maybe a little misunderstanding. Oleg reported a memory
exhaustion problem on COPY FROM in the same context (which
also happened on large updates). I've tracked that down in
the executor. It was because his table had a CHECK clause and
that got stringToNode()'ed for each single tuple.
This problem is fixed in CURRENT along with a speedup of
factor 2++ for the case of CHECK on large ranges. The check's
are only once stringToNode()'ed now and live until the
executor's memory context get's destroyed (the portal level
the plan is executed in).
I don't know if the same caused the VACUUM problem. Oleg,
could you please check against the CURRENT source tree if the
problem still exists?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-02-08 16:56:49 | Re: Commercial support, was Re: [HACKERS] v6.4.3 ? |
Previous Message | Tom Lane | 1999-02-08 16:34:20 | Re: [HACKERS] trouble with rules |