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:
http://www.postgresql.org/mailpref/pgsql-hackers
