From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Can't compile with profiling after BRIN autosummarization |
Date: | 2017-04-03 16:59:08 |
Message-ID: | CAMkU=1wrymb0VveZrcQz3V=AXNRuPiYMVYQO_aMdPgm0yR+2Zg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 3, 2017 at 9:31 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> make maintainer-clean > /dev/null ; ./configure --enable-profiling >
> /dev/null && make -j8 >/dev/null
>
> In file included from ipc.c:29:
> ../../../../src/include/postmaster/autovacuum.h:73: error: expected
> declaration specifiers or '...' before 'BlockNumber'
> make[4]: *** [ipc.o] Error 1
> make[3]: *** [ipc-recursive] Error 2
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [storage-recursive] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [all-backend-recurse] Error 2
> make: *** [all-src-recurse] Error 2
>
>
> This git bisects down to:
>
> commit 7526e10224f0792201e99631567bbe44492bbde4
> Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> Date: Sat Apr 1 14:00:53 2017 -0300
>
> BRIN auto-summarization
>
> The lines are:
>
> extern void AutoVacuumRequestWork(AutoVacuumWorkItemType type,
> Oid relationId, BlockNumber blkno);
>
> I have no idea why --enable-profiling would change the way this line is
> seen.
>
> gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
>
A newer gcc gave a better error message which lead me to add the line:
#include "storage/block.h" /* for typedef BlockNumber */
into autovacuum.h, which fixes the problem.
I don't know if that is the correct fix, or why it is only needed under
profiling.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Keith Fiske | 2017-04-03 17:15:26 | Re: pg_partman 3.0.0 - real-world usage of native partitioning and a case for native default |
Previous Message | Kevin Grittner | 2017-04-03 16:33:07 | Re: GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree" |