|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"?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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. 
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?
|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|