From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgbf(at)twiska(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: snapper vs. HEAD |
Date: | 2020-03-30 02:10:46 |
Message-ID: | 19123.1585534246@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2020-03-30 02:16:53 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Previous Message | Andres Freund | 2020-03-30 02:08:14 | Re: backup manifests |