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. 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'm not sure that that's good enough, and I'm damn sure that it shouldn't be undocumented. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers