FullTransactionId changes are causing portability issues

Поиск
Список
Период
Сортировка
От Tom Lane
Тема FullTransactionId changes are causing portability issues
Дата
Msg-id 27054.1558533367@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: FullTransactionId changes are causing portability issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: "long" type is not appropriate for counting tuples