Horton

Re: Cannot find a working 64-bit integer type on Illumos

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-12-04T06:19:32Z
Lists: pgsql-hackers 
Thomas Munro <thomas.munro@gmail.com> writes:
> A couple of armv7 animals seemed to die in the Perl tests.  Huh.  Well
> I know that Perl was sensitive to this stuff but it passed on 32 bit
> CI (x86).  I will try to reproduce that on local ARM hardware...

turaco seems unhappy because of

2024-12-04 05:37:14.831 GMT [9584:18] pg_regress/plperl_setup LOG:  statement: CREATE EXTENSION plperl;
Util.c: loadable library and perl binaries are mismatched (got first handshake key 0xa300080, needed 0xa400080)

Not clear to me what these changes would have done to trigger that.

			regards, tom lane

Commits

  1. Move pg_int64 back to postgres_ext.h

  2. pgbench: Make set_random_seed() 64-bit everywhere.

  3. Use PRI?64 instead of "ll?" in format strings (continued).

  4. Fix order of -I switches for building pg_regress.o.

  5. libpq: Deprecate pg_int64.

  6. Use PRI*64 instead of "ll*" in format strings (minimal trial)

  7. Fix header inclusion order in c.h.

  8. Use <stdint.h> and <inttypes.h> for c.h integers.

  9. Remove traces of BeOS.

  10. More correct way to check for existence of types, which allows to specify