From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: casting operand to proper type in BlockIdGetBlockNumber |
Date: | 2022-03-03 20:31:51 |
Message-ID: | 3349756.1646339511@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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-03-03 21:07:37 | Re: [Proposal] Global temporary tables |
Previous Message | Greg Stark | 2022-03-03 20:28:52 | Re: [Proposal] Global temporary tables |