Re: master make check fails on Solaris 10

From: Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: vitus(at)wagner(dot)pp(dot)ru, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: master make check fails on Solaris 10
Date: 2018-01-18 09:53:19
Message-ID: 0e183c12a68af526ebc03c5c26206c44@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you!

On 17-01-2018 19:33, Tom Lane wrote:
> Attached is a draft patch to incorporate Victor's slimmed-down test
> into configure. If you have a chance, could you confirm it does
> the right thing on your Sparc machine?

> Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> writes:
>> It seems that what it does is not exactly a right thing.
>> I've applied it to commit 9c7d06d60680 in master and see following
>> checking for __int128 alignment bug... ok
>> As far as I understand your patch, there should be:
>> checking for __int128 alignment bug... broken
> ...
>> Then in the pg_config.h I see
>> /* The normal alignment of `PG_INT128_TYPE', in bytes. */
>> #define ALIGNOF_PG_INT128_TYPE 16
>> /* Define to the name of a signed 128-bit integer type. */
>> #define PG_INT128_TYPE __int128
> ...
>> However, make check passes.
> Uh ... how could that be? If the output of configure is exactly
> the same as before the patch, how could the end result be different?

Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
and using the configuration command from [1], I got:
checking for __int128... yes
checking for __int128 alignment bug... broken

Nothing is defined for int128 in pg_config.h:
/* The normal alignment of `PG_INT128_TYPE', in bytes. */
/* #undef ALIGNOF_PG_INT128_TYPE */
...
/* Define to the name of a signed 128-bit integer type. */
/* #undef PG_INT128_TYPE */

And make check-world passes. Victor said that he used a much simpler
configuration command, and I'm trying to figure out what's changed..

> BTW, it would be a good idea to set up a buildfarm member on that
> machine, if you care about whether that configuration continues
> to work in the future.

Victor answered this in [2]:
> Really we already have buildfarm member on this machine. It is just
> member of PostgresPro private buildfarm, not of big comminity
> buildfarm.
>
> So, I'll register it in the big buildfarm as soon as I figure out how
> to distribute limited resources of this machine between two buildfarms.

P.S. I found the trailing whitespace in line 80:
! int128a q;

[1]
https://www.postgresql.org/message-id/0d3a9fa264cebe1cb9966f37b7c06e86%40postgrespro.ru
[2]
https://www.postgresql.org/message-id/20180117203648.2626d97a%40wagner.wagner.home

--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-01-18 09:54:18 Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables
Previous Message Amit Langote 2018-01-18 09:28:14 Re: [Sender Address Forgery]Re: pg_(total_)relation_size and partitioned tables