Re: Re: [COMMITTERS] pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeremy Drake <pgsql@jdrake.com>
Cc: Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@commandprompt.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2011-09-04T07:29:00Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove unnecessary #include references, per pgrminclude script.
- 6416a82a62db 9.2.0 cited
-
Remove "fmgr.h" include in cube contrib --- caused crash on a Gentoo
- d5321842528d 9.2.0 cited
-
Allow more include files to be compiled in their own by adding missing
- 4bd7333b1478 9.2.0 cited
-
Add support for #elif to pgrminclude.
- d010391ac8f7 9.2.0 cited
Jeremy Drake <pgsql@jdrake.com> writes: > On Sun, 4 Sep 2011, Tom Lane wrote: >> Right now I have a feeling that this is a compiler bug. > That's my feeling, also. >> Don't know >> whether you have the interest/energy to try to reduce it to a reportable >> test case. > If you mean reporting it to the compiler vendor (Intel), I doubt that > would be worthwhile. The version of the compiler on this machine is very > out of date. It is version 9.0 20060222. I would bet that if I did track > down and report an issue in a 5-year-old compiler version, their first > question would be, does the issue duplicate in the current version. Given > that my other buildfarm member is running 11.1 20100414 (albeit for the > x64 platform instead of the x86) and had no issue, I would expect that the > current x86 version would also have no problem. > I have intentionally been keeping the compiler versions on my buildfarm > members pretty much fixed, for the benefit of reproducable results. > However, I would be interested in hearing any guidelines on "how old is > too old" for buildfarm member versions. Well, I'm still running this on one development machine: $ gcc -v Reading specs from /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.3/specs gcc version 2.95.3 20010315 (release) so I'm not in the "it's too old" camp. My perspective on tool bugs is whether there is something (a) well defined and (b) not costly that we can do to work around it. So far, this issue is failing test (a) ... we know that one header inclusion order triggers the crash and another not, but there is no theory as to why. What I would suggest is to see whether a more recent x86 version shows the problem or not. If not, let's just write it off as an already-fixed compiler bug. regards, tom lane