Re: remove ATTRIBUTE_FIXED_PART_SIZE

On August 24, 2018 9:16:27 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2018-08-24 11:47:43 -0400, Tom Lane wrote:
>>> Um ... this would be enough to document that we don't think there's
>a
>>> *read* hazard, but Andres was claiming that there's also a *write*
>hazard.
>
>> Right. The relevant standardese, in C11 (C99 very similar), is:
>> 6.2.6.1 General, 6):
>> "When a value is stored in an object of structure or union type,
>including in a member
>> object, the bytes of the object representation that correspond to any
>padding bytes take
>> unspecified values."
>
>> I don't have the references at hand, but I'm fairly sure that at
>least
>> gcc and clang can be made to exploit that.
>
>Thing is, if that's true, why have we not seen field reports of catalog
>corruption problems? Maybe we're just fortunate that we don't try to
>update the last fixed field of any catalog that way?

I suspect that the code doing so usually is "too boring" to present many chances for optimization. And that, as you say, we largely update earlier fields (without resorting to deforming and forming the tuple at least).

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.