Re: snapper vs. HEAD

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: snapper vs. HEAD
Дата
Msg-id 20200330005610.qqe73ybfd4awclw5@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: snapper vs. HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: snapper vs. HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: snapper vs. HEAD  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2020-03-29 20:25:32 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > If you still have the environment it might make sense to check wether
> > it's related to one of the other options. But otherwise I wouldn't be
> > against the proposal.
> 
> 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.


> (I guess we can exclude LDFLAGS, since the assembly output is visibly
> bad.)

Seems likely.

Is it visibly bad when looking at the .s of gistget.c "directly", or
when disassembling the fiinal binary? Because I've seen linkers screw up
on a larger scale than I'd have expected in the past.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: backup manifests
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [PATCH] Redudant initilization