On Thu, Mar 3, 2022 at 1:11 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2022-03-03 15:31:51 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2022-03-03 14:00:14 -0500, Tom Lane wrote: > > 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.
The sanitizers are documented to work best on linux... As flaviventris runs linux, so I'm not sure what your concern is?
I think basically newer glibc versions have more annotations, so ubsan will have more things to fail against. So it'd be good to have a fairly regularly updated OS.
> 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.
The compilation flags make it look like it's from a run of yugabyte's fork, rather than plain postgres.
Hi,
I should mention that, the PG subtree in yugabyte is currently aligned with PG 11.
There have been backports from PG 12, but code related to tid.c and block.h, etc is the same with upstream PG.
The fdw tests are backported from PG as well.
The message says: src/backend/utils/adt/tid.c:112:16: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int'
Afaics that means bi_hi is 65535. So either we're dealing with a very large relation or BlockIdGetBlockNumber() is getting passed InvalidBlockNumber?
It might be enough to do something like SELECT * FROM pg_class WHERE ctid = '(65535, 17)'; to trigger the problem?
The above syntax is not currently supported in yugabyte.
