On 2014-04-08 09:37:33 -0400, Tom Lane wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
> > On 2014-04-07 21:47:38 -0400, Tom Lane wrote:
> >> Well, that is certainly messy.  I think you could just use a local
> >> HeapTupleData variable instead of palloc'ing every time, where "local"
> >> means "has lifespan similar to the slot pointer".
> >> There's some vaguely similar hacking near the end of ExecDelete.
> > Yea, and some other places. I wonder if a ExecShallowMaterializeSlot()
> > or something would be useful for me, that callsite and others?
> Don't like that name much, but I agree there's some room for a function
> like this.

I am not the biggest fan either, for one it's really rather long, for
another it's not really descriptive. One might think it's about toast or
something. Do you have a better name?

> I guess you're imagining that we'd add a HeapTupleData field
> to TupleTableSlots, and use that for the workspace when this situation
> arises?

I wasn't really sure about the approach yet. Either do something like
you describe (possibly reusing/recoining tts_minhdr?), or just allocate
a HeapTupleData struct.

> An alternative possibility would be to not invent a new function, but
> just make ExecStoreTuple do this unconditionally when shouldFree=false.
> Not sure if there'd be a noticeable runtime penalty.

I think that's a viable alternative.

> I know I've always thought
> of slots as being fully independent storage, and in this case they
> are not.

Me to. I was initially rather confused by the memory corruptions I was
seeing. I really thought that storing a tuple pointing to a buffer in
the slot should "just work".


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to