Re: Does TupleQueueReaderNext() really need to copy its result?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Does TupleQueueReaderNext() really need to copy its result?
Дата
Msg-id 20190826183510.yzumatbtq32px3et@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Does TupleQueueReaderNext() really need to copy its result?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Does TupleQueueReaderNext() really need to copy its result?  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: range_agg
Следующее
От: Tom Lane
Дата:
Сообщение: Re: "ago" times on buildfarm status page