On 2017-08-16 13:40:09 -0400, Tom Lane wrote: > I wrote: > > I can confirm that on dromedary, that regression test case is attempting > > to create a TOC with a not-well-aligned size: 93268 = 0x16c54 bytes. > > ... although, on closer look, it still seems like we have a fundamental > bit of schizophrenia here, because on this machine > > $ grep ALIGN pg_config.h > #define ALIGNOF_DOUBLE 4 > #define ALIGNOF_INT 4 > #define ALIGNOF_LONG 4 > #define ALIGNOF_LONG_LONG_INT 4 > #define ALIGNOF_SHORT 2 > #define MAXIMUM_ALIGNOF 4 > > Basically, therefore, ISTM that it is not a good thing that the atomics > code thinks it can rely on 8-byte-aligned data when the entire rest of > the system believes that 4-byte alignment is enough for anything.
That's a hardware requirement, we can't do much about it. Several [micro-]architectures don't support unaligned atomic 8 byte writes. > I was wondering why the shm_toc code was using BUFFERALIGN and not > MAXALIGN, and I now suspect that the answer is "it's an entirely > undocumented kluge to make the atomics code not crash on 32-bit > machines, so long as nobody puts a pg_atomic_uint64 anywhere except in > a shm_toc". I don't think there were any atomics in affected code until earlier today... And given it didn't work for shm_toc anyway, I'm not quite following. > I'm not sure that that's good enough, and I'm damn sure that it > shouldn't be undocumented. 8 byte alignment would be good enough, so BUFFERALIGN ought to be sufficient. But it'd be nicer to have a separate more descriptive knob. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
