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@sun.med.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
justGOSUB without RETURN.