Re: [HACKERS] strange behaviour on pooled alloc (fwd)

Поиск
Список
Период
Сортировка
От jwieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] strange behaviour on pooled alloc (fwd)
Дата
Msg-id m109Ut9-000EBPC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Список pgsql-hackers
Vadim,

I wrote:
>     New version of AllocSet...() functions is committed. palloc()
>     is a macro now. The  memory  eating  problem  of  COPY  FROM,
>     INSERT ... SELECT and UPDATES on a table that has constraints
>     is fixed (new file nodes/freefuncs.c).
>
>     The settings in aset.c aren't optimal for  now,  because  the
>     settings in place force the portals_p2 test to fail (at least
>     here). Some informations for those who want to take a look at
>     it follow.
>
>     Reproducing the bug:
>         [...]
>
>     Guessings:
>         [...]

    The  guess  that some memory get's corrupted where right. The
    area affected is something else.

>     I'll keep on debugging, but  would  be  very  appreciated  if
>     someone could help.

    I love  gdb!  Wasn't  easy  to  find,  and  would  have  been
    impossible without such a nice, smart tool.

    The  problem was caused by QuerySnapshot beeing free()'d if a
    transaction uses many portals. In ExecutorStart(), the actual
    QuerySnapshot is placed into the execution state, and that is
    used subsequently for HeapTupleSatisfies() deep  down  during
    ExecutePlan().

    In  the  case  of  portals, every DECLARE CURSOR results in a
    call to  ExecutorStart().  The  corresponding  ExecutorEnd(),
    where  the  execution  state is thrown away, is delayed until
    CLOSE.

    The  tcop  calls  SetQuerySnapshot()  before  any   call   to
    ExecutorStart().    So   if   someone   opens  many  cursors,
    SetQuerySnapshot() free's snapshot data that  will  later  be
    needed when FETCH has to scan relations.

    I have modified ExecutorStart() so it makes it's private copy
    of the actual  QuerySnapshot  in  it's  own  executor  memory
    context. Could you please comment if what is in QuerySnapshot
    at the time of ExecutorStart() get's or should  get  modified
    anywhere  during  the  execution of a plan. The name snapshot
    tells me NOT. But you're the one to judge.

    Please have a look at it and comment.


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 по дате отправления:

Предыдущее
От: Peter T Mount
Дата:
Сообщение: Re: [HACKERS] Problems with >2GB tables on Linux 2.0
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] One I've never seen before: