Re: [HACKERS] VACUUM ANALYZE problem on linux

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.

regards, tom lane

>
> 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) #

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.

> 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?

I can test on libc5 if you still see trouble after you have verified
Jan's fixes for your memory exhaution problem.

Let me know...

- Tom

Hello!

On Tue, 9 Feb 1999, Thomas G. Lockhart wrote:
> I can test on libc5 if you still see trouble after you have verified
> Jan's fixes for your memory exhaution problem.

I've downloaded latest snapshot (9 Feb) and reproduced the problem with
VACUUM ANALYZE on Debian 2.0 (glibc2).

Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2(at)earthling(dot)net
Programmers don't die, they just GOSUB without RETURN.