Did this add to the "ways in which [HeapTupleData] is used"?

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Did this add to the "ways in which [HeapTupleData] is used"?
Date: 2021-11-09 21:49:00
Message-ID: 618AECCC.4000806@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


I notice, belatedly, that 141fd1b tweaked the order of some members of
struct catctup, moving c_list and my_cache from earlier locations to the
end of the struct. [0]

That resulted in this sequence at the end of the struct:

HeapTupleData tuple; /* tuple management header */
struct catclist *c_list; /* containing CatCList, or NULL if none */
CatCache *my_cache; /* link to owning catcache */
/* properly aligned tuple data follows, unless a negative entry */

It works, of course, with tuple->t_data pointed appropriately to the aligned
spot after the struct. But does this add a new variant to the possible
situations described in the htup.h comments?

* * Part of a palloc'd tuple: the HeapTupleData itself and the tuple
* form a single palloc'd chunk. t_data points to the memory location
* immediately following the HeapTupleData struct (at offset
* * 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. ...

Am I right in thinking that created a new case where the HeapTupleData
and the tuple are not adjacent, but also not separately allocated?
Would that perhaps warrant a mention in those comments in htup.h?



Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-09 22:20:41 Frontend error logging style
Previous Message Andrew Dunstan 2021-11-09 21:34:34 Re: Commitfest 2021-11 Patch Triage - Part 2