Re: casting operand to proper type in BlockIdGetBlockNumber

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: casting operand to proper type in BlockIdGetBlockNumber
Дата
Msg-id 3349756.1646339511@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: casting operand to proper type in BlockIdGetBlockNumber  (Andres Freund <andres@anarazel.de>)
Ответы Re: casting operand to proper type in BlockIdGetBlockNumber  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-03-03 14:00:14 -0500, Tom Lane wrote:
>> I'm not sure whether to back-patch --- looking through the
>> git logs, it seems we've back-patched some fixes like these
>> and not others.  Thoughts?

> It'd be easier to run a BF animal if we fixed it everywhere.

Fair enough, will BP.

>> In any case, if we're going to take this seriously it seems like we need a
>> buildfarm machine or two testing this option.

> For the buildfarm, I could enable it on flaviventris? That runs an
> experimental gcc, without optimization (whereas serinus runs with
> optimization). Which seems reasonable to combine with sanitizers?

Dunno.  I already found out that my Mac laptop (w/ clang 13) detects
the numeric.c problem but not any of the other ones.  The messages
on RHEL8 cite where the system headers declare memcmp and friends
with "attribute nonnull", so I'm betting that Apple's headers lack
that annotation.

I also tried adding the various -m switches shown in Zhihong's
CFLAGS setting, but that still didn't repro the Alma warning
for me.

So it definitely seems like it's *real* system dependent which of
these warnings you get :-(.

            regards, tom lane



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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [Proposal] Global temporary tables
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [Proposal] Global temporary tables