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 d
Thomas Munro writes:
> If there is any system where sizeof(FormData_pg_attribute) !=
> (offsetof(FormData_pg_attribute,attcollation) + sizeof(Oid)), won't
> load_relcache_init_file() get upset? Oh, I see it would just go to
> read_failed and then "do it the hard way".
Right, so we needn't includ
On Thu, Jan 4, 2018 at 12:29 PM, Thomas Munro
wrote:
> If there is any system where sizeof(FormData_pg_attribute) !=
> (offsetof(FormData_pg_attribute,attcollation) + sizeof(Oid)), won't
> load_relcache_init_file() get upset? Oh, I see it would just go to
> read_failed and then "do it the hard wa
On Thu, Jan 4, 2018 at 12:01 PM, Tom Lane wrote:
> Thomas Munro 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
Thomas Munro 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
>
On 11/29/2017 08:58 AM, Thomas Munro wrote:
> Hi hackers,
>
> 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 u
