Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity
Date
Msg-id 25466.1515051830@sss.pgh.pa.us
Whole thread Raw
In response to Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> 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.

After further study I think this is a false alarm.  valgrind doesn't
actually whine when you memcpy some undefined bytes: it just propagates
the undefined-ness of those bytes to the destination, and complains only
if the program uses the destination bytes to do something meaningful.
(Were this not so, copying structs containing embedded padding bytes
would always cause bogus warnings.)

There might still be value in redefining ATTRIBUTE_FIXED_PART_SIZE as
sizeof(FormData_pg_attribute), but I'm not sure, and am sort of inclined
to leave it alone.

            regards, tom lane


pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Libpq support to connect to standby server as priority
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] UPDATE of partition key