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

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(at)debis(dot)com (Jan Wieck) #