Re: [HACKERS] VACUUM ANALYZE problem on linux

Hello!

I'll try CURRENT a bit later (things gonna get real slow these days :).
But I am sure these are two different problems.

First, I had memory problem on a big table, and VACUUM ANALYZE problem
on two very small tables (few lines).

Second, I have memory problem on 3 systems - RedHat 5.1 on Pentium,
Debian 2.0 on Pentium, and Solaris on Ultra-1.
But I have VACUUM ANALYZE problem only on linucies.

BTW, I noted bot linucies are glibc2-based. It would be interesting to
try libc5-based system. May be we can narrow the problem down to
glibc2-based linux?
Have someone libc5-based linux ready to test?

On Mon, 8 Feb 1999, Jan Wieck wrote:
> >
> > 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?

Oleg.
----
Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/
Programmers don't die, they just GOSUB without RETURN.