On Sun, Feb 26, 2017 at 07:53:15PM -0500, Tom Lane wrote:
> Noah Misch <n...@leadboat.com> writes:
> > Dear 7b4ac19 authors,
> > Field ps_snapshot_data usually receives four-byte alignment within
> > ParallelIndexScanDescData, but it contains the eight-byte whenTaken field.
> > The select_parallel test dies with SIGBUS on "Oracle Solaris 10 1/13
> > s10s_u11wos_24a SPARC", building with gcc 4.9.2.
> It's a little distressing that the buildfarm didn't find this already.
> Is there some reason why it's specific to that particular compiler,
> rather than generic to alignment-picky 64-bit machines?

I wondered the same thing; if nothing else, why don't protosciurus and
castoroides fail the same way?  They do use older compilers, "Sun C 5.10
SunOS_sparc 2009/06/03" and gcc 3.4.3.  I have "Sun C 5.12 SunOS_sparc
2011/11/16" and gcc 4.9.2, both of which are alignment-sensitive in several
configurations, according to the attached test program.  However, in a 32-bit
build with this Sun C, I don't get alignment-related bus errors.  (Those
animals build 64-bit, so this isn't the full story.)

> In general, though, I agree that using a char[] member to represent
> anything that has any alignment requirement at all is seriously bad
> coding style that is almost certain to fail eventually.
> A solution you didn't mention is to change the ParallelIndexScanDescData
> field to be a pointer, perhaps "struct SerializedSnapshotData *", while
> leaving that struct opaque so far as relscan.h is concerned.  This could
> avoid the need to use the unsafe blind casts that I'm sure must be
> involved in accesses to that field at present.

That, too, would be reasonable.
/* run with: for n in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do ./a.out $n; 
done */

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
    char foo[] = "abcdefghijklmnopqrstuvwxyz";
    if (argc != 2)
        puts("bad usage");
        return 1;

    printf("%llx\n", *(long long *)(foo + atoi(argv[1])));
    return 0;
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to