Re: casting operand to proper type in BlockIdGetBlockNumber
Zhihong Yu <zyu@yugabyte.com>
From: Zhihong Yu <zyu@yugabyte.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-03-03T21:21:39Z
Lists: pgsql-hackers
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. FYI
Commits
-
Tighten overflow checks in tidin().
- f7ea240aa749 15.0 landed
-
Remove some pointless code in block.h.
- 8134fe4ad80a 15.0 landed
-
Fix bogus casting in BlockIdGetBlockNumber().
- 18c04d157456 10.21 landed
- 566e1c04df52 11.16 landed
- 4b0696b36e5a 12.11 landed
- 97031f440485 13.7 landed
- 5c9d17e94c5c 14.3 landed
- 0fbdfaf79d0b 15.0 landed
-
Clean up assorted failures under clang's -fsanitize=undefined checks.
- f727b6ea8f3b 12.11 landed
- f2087e26ebf1 11.16 landed
- cfbe87bd6f64 10.21 landed
- b0bc196e52e6 14.3 landed
- 46ab07ffda9d 15.0 landed
- 1a027e6b7bdf 13.7 landed