From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | FullTransactionId changes are causing portability issues |
Date: | 2019-05-22 13:56:07 |
Message-ID: | 27054.1558533367@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | buildfarm-members pgsql-hackers |
Our Solaris packager reports that 12beta1 is failing to build for him
on some Solaris variants:
> The link failure is:
> ---
> Undefined first referenced
> symbol in file
> ReadNextFullTransactionId pg_checksums.o
> ld: fatal: symbol referencing errors. No output written to pg_checksums
> ---
> Now, ReadNextFullTransactionId() is implemented in
> src/backend/access/transam/varsup.c but I cannot see varsop.o being
> included in any of the libraries pg_checksum is linked against
> (libpgcommon.a and libpgport.a).
> When I check the pg_checksum.o I find that it references
> ReadNextFullTransactionId on the platforms that fail but not where it
> doesn't. The failed platforms are all sparc variants plus 64-bit x86
> on Solaris 11.
> The compiler used in Sun Studio 12u1, very old and and I can try to
> upgrade and see if that helps.
> [ it didn't ]
I'm a bit mystified why we did not see this problem in the buildfarm,
especially since we have at least one critter (damselfly) running an
OpenSolaris variant. Nonetheless, it sure looks like a "somebody
was sloppy about frontend/backend separation" problem.
Fix ideas anyone? I think we need to not only solve the immediate
problem (which might just take an #ifndef FRONTEND somewhere) but
also close the testing gap so we don't get blindsided like this
again.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-05-22 14:48:08 | Re: FullTransactionId changes are causing portability issues |
Previous Message | Andrew Dunstan | 2019-04-04 22:54:39 | Re: PostgreSQL Buildfarm Client Release 10 |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-05-22 14:39:41 | Re: "long" type is not appropriate for counting tuples |
Previous Message | Tom Lane | 2019-05-22 13:46:19 | Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD |