|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
|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|