| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: remove ATTRIBUTE_FIXED_PART_SIZE |
| Date: | 2018-08-24 16:16:27 |
| Message-ID: | 15865.1535127387@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-08-24 16:19:45 | Re: remove ATTRIBUTE_FIXED_PART_SIZE |
| Previous Message | Tom Lane | 2018-08-24 16:10:34 | Re: Windows vs C99 (was Re: C99 compliance for src/port/snprintf.c) |