Re: [HACKERS] VACUUM ANALYZE problem on linux

Поиск
Список
Период
Сортировка
Искать
От
jwieck@debis.com (Jan Wieck)
Тема
Re: [HACKERS] VACUUM ANALYZE problem on linux
Дата
Msg-id
m109tmj-000EBRC@orion.SAPserv.Hamburg.dsh.de
Ответ на
Список
Дерево обсуждения
VACUUM ANALYZE problem on linux Oleg Broytmann <phd@sun.med.ru>
Re: [HACKERS] VACUUM ANALYZE problem on linux Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] VACUUM ANALYZE problem on linux jwieck@debis.com (Jan Wieck)
Re: [HACKERS] VACUUM ANALYZE problem on linux Oleg Broytmann <phd@sun.med.ru>
>
> Oleg Broytmann  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@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: Tom Lane
Дата:
FAQ