| 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: | Whole Thread | Raw Message | 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. |