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-03 23:01:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

regards, tom lane

Attachment Content-Type Size
rationalize-attribute-fixed-part-size.patch text/x-diff 3.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-03 23:04:03 Re: LIKE foo% optimization easily defeated by OR?
Previous Message Alexander Korotkov 2018-01-03 23:00:17 Re: [HACKERS] Pluggable storage