Re: snapper vs. HEAD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: snapper vs. HEAD
Date
Msg-id 19123.1585534246@sss.pgh.pa.us
Whole thread Raw
In response to Re: snapper vs. HEAD  (Andres Freund <andres@anarazel.de>)
Responses Re: snapper vs. HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2020-03-29 20:25:32 -0400, Tom Lane wrote:
>> I could, but it's mighty slow, so I don't especially want to try all 2^N
>> combinations.  Do you have any specific cases in mind?

> I'd be most suspicious of -fstack-protector --param=ssp-buffer-size=4
> and -D_FORTIFY_SOURCE=2. The first two have direct codegen implications,
> the latter can lead to quite different headers being included and adds a
> lot of size tracking to the optimizer.

It occurred to me that just recompiling gistget.c, rather than the whole
backend, would be enough to prove the point.  So after a few trials:

* Removing "-fstack-protector --param=ssp-buffer-size=4" does nothing;
the generated .o file is bitwise the same.

* Removing -D_FORTIFY_SOURCE=2 does change the bits, but it still
crashes.

So that eliminates all of snapper's special compile options :-(.
I'm forced to the conclusion that the important difference between
snapper and skate is that the latter uses --enable-cassert and the
former doesn't, because that's the only remaining difference between
how I built a working version before and the not-working version
I have right now.  Which means that this really is pretty much a
phase-of-the-moon compiler bug, and we've just been very lucky
that we haven't tripped over it before.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: backup manifests
Next
From: James Coleman
Date:
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)