Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> Andrew Gierth complained off-list that TupleDescCopy() doesn't clear
> atthasdef. Yeah, that's an oversight. The function is new in commit
> cc5f81366c36 and was written by me to support "flat" (pointer-free)
> tuple descriptors for use in DSM. Following the example of
> CreateTupleDescCopy() I think it should also clear attnotnull and
> attidentity. Please see attached.

I've pushed this with some editorialization. I added some comments, and
noting that you have TupleDescCopy() copying the entire attribute array
in one memcpy, I propagated that same approach into CreateTupleDescCopy
and CreateTupleDescCopyConstr. This should make things a bit faster
since memcpy can spend more time in its maximum-stride loop.

The reason I note this explicitly is that I don't find it to be
entirely safe. If ATTRIBUTE_FIXED_PART_SIZE were less than
sizeof(FormData_pg_attribute) due to alignment padding at the end of
the struct, I think we would get some valgrind complaints about copying
uninitialized data, since there are code paths in which only the first
ATTRIBUTE_FIXED_PART_SIZE bytes of each array entry get filled in.
Now, currently I don't think there's any padding there anyway on any
platform we support. But if we're going to do things like this, I think
that we ought to explicitly make ATTRIBUTE_FIXED_PART_SIZE the same as
sizeof(FormData_pg_attribute). Hence, I propose the attached follow-on
patch.

regards, tom lane