Re: Does TupleQueueReaderNext() really need to copy its result? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Does TupleQueueReaderNext() really need to copy its result?
Date
Msg-id 20190826183510.yzumatbtq32px3et@alap3.anarazel.de
Whole thread Raw
In response to Re: Does TupleQueueReaderNext() really need to copy its result?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Does TupleQueueReaderNext() really need to copy its result?  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Hi,

On 2019-08-26 14:09:45 -0400, Robert Haas wrote:
> On Fri, Aug 23, 2019 at 10:22 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > Couldn't resist trying this, and it seems to work.  Based on the
> > comment "the buffer size is a multiple of MAXIMUM_ALIGNOF, and each
> > read and write is as well", it should always work (though I wish
> > shm_mq_receive_bytes()'s documentation would discuss message alignment
> > explicitly if that's true).  On the other hand, I doubt it makes a
> > difference, so this is more of a question: is this the way it was
> > supposed to work?
> 
> There's a comment in htup.h which says:
> 
>  * * Separately allocated tuple: t_data points to a palloc'd chunk that
>  *       is not adjacent to the HeapTupleData.  (This case is deprecated since
>  *       it's difficult to tell apart from case #1.  It should be used only in
>  *       limited contexts where the code knows that case #1 will never apply.)
> 
> I got scared and ran away.

Perhaps this'd could be sidestepped by funneling through MinimalTuples
instead of HeapTuples. Afaict that should always be sufficient, because
all system column accesses ought to happen below (including being
projected into a separate column, if needed above). With the added
benefit of needing less space, of course.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: range_agg
Next
From: Tom Lane
Date:
Subject: Re: "ago" times on buildfarm status page