Andres Freund <and...@anarazel.de> writes:
> On August 18, 2018 8:37:00 PM GMT+02:00, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Meh, I'm not sure about this. What about the possibility of trailing
>> padding after the last fixed column, as the comment you propose to
>> remove is talking about? Sure, we don't have that today, but we
>> might again the next time somebody adds a column to pg_attribute.
> Where would avoiding that padding be an important thing her? Strictly
> speaking it's not even safe to access the last members without the padding
> present - the compiler is free to store with a wider write if that just
> affects padding. GCC does that in some cases IIRC.
If that's true, it's causing problems already, no? If you've got
something like
int somefield;
bool someflag;
#ifdef CATALOG_VARLEN
text somevarlena;
#endif
then our tuple packing rules will feel free to put the text value
immediately adjacent to the bool, when it's short-header. According
to what you're saying, code that tries to update "someflag" in a tuple
risks corrupting the text value.
Contrariwise, if the varlena field is NULL, there won't be any valid
data at all after the bool. You would get away with copying the tuple
using a word-aligned struct definition anyway, physically, but I bet
valgrind would be unhappy with you.
Possibly we need to be more careful than we are now about whether
there's padding at the end of the fixed-size fields ... but just
ripping out the code that attempts to deal with that is hardly
an improvement.
regards, tom lane
