From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Macro nesting hell |
Date: | 2015-07-01 15:55:48 |
Message-ID: | 20150701155548.GD3289@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Last night my ancient HP compiler spit up on HEAD:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pademelon&dt=2015-07-01%2001%3A30%3A18
> complaining thus:
> cpp: "brin_pageops.c", line 626: error 4018: Macro param too large after substitution - use -H option.
> I was able to revive pademelon by adding a new compiler flag as suggested,
> but after looking at what the preprocessor is emitting, I can't say that
> I blame it for being unhappy. This simple-looking line
>
> Assert(BRIN_IS_REGULAR_PAGE(BufferGetPage(oldbuf)));
>
> is expanding to this:
Wow, that's kind of amazing. I think this particular case boils down to
just PageGetSpecialPointer (bufpage.h) and BufferGetBlock (bufmgr.h).
> I'm thinking we really ought to mount a campaign to replace some of these
> macros with inlined-if-possible functions.
My guess is that changing a very small amount of them will do a large
enough portion of the job.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2015-07-01 16:06:36 | Re: Freeze avoidance of very large table. |
Previous Message | Simon Riggs | 2015-07-01 15:28:56 | Re: Freeze avoidance of very large table. |