Re: Can't compile with profiling after BRIN autosummarization

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

In response to

Responses

Browse pgsql-hackers by date

  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"