On 2015-08-05 23:18:08 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > ... I'm going to reshuffle things in that direction tomorrow. I'll
> > wait for other fallout first though. So far only gcc, xlc and clang (via
> > gcc frontend) have run...
>
> In the department of "other fallout", pademelon is not happy:
>
> cc -Ae -g +O0 -Wp,-H16384 -I../../../src/include -D_XOPEN_SOURCE_EXTENDED
> -I/usr/local/libxml2-2.6.23/include/libxml2 -I/usr/local/include -c -o
> pg_resetxlog.o pg_resetxlog.c
> cc -Ae -g +O0 -Wp,-H16384 pg_resetxlog.o -L../../../src/port
> -L../../../src/common -L/usr/local/libxml2-2.6.23/lib -L/usr/local/lib -Wl,+b
> -Wl,'/home/bfarm/bf-data/HEAD/inst/lib' -Wl,-z -lpgcommon -lpgport -lxnet
> -lxml2 -lz -lreadline -ltermcap -lm -o pg_resetxlog
> /usr/ccs/bin/ld: Unsatisfied symbols:
> pg_atomic_clear_flag_impl (code)
> pg_atomic_init_flag_impl (code)
> pg_atomic_compare_exchange_u32_impl (code)
> pg_atomic_fetch_add_u32_impl (code)
> pg_atomic_test_set_flag_impl (code)
> pg_atomic_init_u32_impl (code)
> make[3]: *** [pg_resetxlog] Error 1
>
> I'd have thought that port/atomics.c would be included in libpgport, but
> it seems not.
Given that it requires spinlocks for the fallback, which in turn may
require semaphores, that didn't seem like a good idea. Thus atomics.c is
in src/backend/port not src/port (just like other locking stuff like
spinlocks, semaphores etc).
> (But is pademelon really the only buildfarm critter relying
> on the "fallback" atomics implementation?)
I don't think so. At least that didn't use to be the case. My guess is
that less ancient compilers don't emit code for unreferenced functions
and this thus doesn't show up.
> Another possible angle is: what the heck does pg_resetxlog need with
> atomic ops, anyway?
It really doesn't. It's just fallout from indirectly including lwlock.h
which includes an atomic variable. The include path leading to it is
In file included from
/home/andres/src/postgresql/src/include/storage/lwlock.h:19:0,
from /home/andres/src/postgresql/src/include/storage/lock.h:18,
from
/home/andres/src/postgresql/src/include/access/tuptoaster.h:18,
from
/home/andres/src/postgresql/src/bin/pg_resetxlog/pg_resetxlog.c:49:
/home/andres/src/postgresql/src/include/port/atomics.h:41:2: error: #error
"THOU SHALL NOT REQUIRE ATOMICS"
#error "THOU SHALL NOT REQUIRE ATOMICS"
There's other path's (slot.h) as well if that were fixed.
> Should these things have a different, stub implementation for FRONTEND
> code?
I'm honestly not yet sure what the best approach here would be.
One approach is to avoid including lwlock.h/slot.h in frontend
code. That'll require some minor surgery and adding a couple includes,
but it doesn't look that bad.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
