On Thu, 2009-03-26 at 12:57 -0400, Tom Lane wrote:
> If work_mem is small enough, that means the tuplestore is
> forced into dump-to-disk mode, which means it releases all its
> in-memory tuples. And guess what: the ScanTupleSlot is pointing at
> one of those, it doesn't have its own copy of the tuple. So we wind
> up trying to read from a trashed bit of memory.
>
> A brute-force solution is to change tuplestore_gettupleslot() so that
> it always copies the tuple, but this would be wasted cycles for most
> uses of tuplestores. I'm thinking of changing
> tuplestore_gettupleslot's API
> to add a bool parameter specifying whether the caller wants to force
> a copy.
>
> Comments, better ideas?
Sounds very similar to the solution that you just removed from the hash
join code for performance reasons. Flushing memory when we overflow
sounds like an artifact from the time when tuplestore split from
tuplesort. Can't we keep the appropriate rows in memory and scroll
through them?
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support