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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: TupleDescCopy doesn't clear atthasdef, attnotnull, attidentity
Date: 2018-01-04 07:43:50
Message-ID: 25466.1515051830@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-01-04 07:54:29 Re: [HACKERS] UPDATE of partition key
Previous Message Tsunakawa, Takayuki 2018-01-04 06:40:39 RE: Libpq support to connect to standby server as priority