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 |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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
HEAPTUPLESIZE). ...
*
* * 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?
Regards,
-Chap
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 |