Re: snapper vs. HEAD

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: snapper vs. HEAD
Дата
Msg-id 19123.1585534246@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: snapper vs. HEAD  (Andres Freund <andres@anarazel.de>)
Ответы Re: snapper vs. HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: backup manifests
Следующее
От: James Coleman
Дата:
Сообщение: Re: [PATCH] Incremental sort (was: PoC: Partial sort)