On Tue, Oct 23, 2018 at 10:51 AM Andres Freund <andres@anarazel.de> wrote:
On 2018-10-23 13:54:31 +0200, Fabien COELHO wrote: > > Hello Tom & Amit, > > > > > Both animals use gcc experimental versions, which may rather underline a > > > > new bug in gcc head rather than an existing issue in pg. Or not. > > > > > It is possible, but what could be the possible theory? > > > > It seems like the two feasible theories are (1) gcc bug, or (2) buffer > > leak that only occurs in very narrow circumstances, perhaps from a race > > condition. Given that the hash index code hasn't changed meaningfully > > in several months, I thought (1) seemed more probable. > > Yep, that is my thought as well.
> The problem is that this kind of issue is not simple to wrap-up as a gcc bug > report, unlike other earlier instances that I forwarded to clang & gcc dev > teams. > > I'm in favor in waiting before trying to report it, to check whether the > probable underlying gcc problem is detected, reported by someone else, and > fixed in gcc head. If it persists, then we'll see.
I suspect the easiest thing to narrow it down would be to bisect the problem in gcc :(
Their commit r265241 is what broke the PostgreSQL build. It also broke the compiler itself--at that commit it was no longer possible to build itself. I had to --disable-bootstrap in order to get a r265241 compiler to test PostgreSQL on.
Their commit r265375 fixed the ability to compile itself, but built PostgreSQL binaries remain broken there and thereafter.
I ran this on a AWS c5d.4xlarge ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-20180912 (ami-0f65671a86f061fcd)
Configuring PostgreSQL with ./configure --enable-cassert is necessary in order for the subsequent "make check" to experience the failure.
I'm using PostgreSQL v12dev commit 5953c99697621174f, but the problem is not sensitive to that and reproduces back to v10.0.
I haven't the slightest idea what to do with this information, and GCC's cryptic SVN commit messages don't offer much insight to me.
