Re: casting operand to proper type in BlockIdGetBlockNumber

From: Zhihong Yu <zyu(at)yugabyte(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: casting operand to proper type in BlockIdGetBlockNumber
Date: 2022-03-03 21:21:39
Message-ID: CALNJ-vQgPWBrhBFHM5y1XMPDLXy8uY4_kVX9EgTGnc_0AeqXiA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 3, 2022 at 1:11 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2022-03-03 15:31:51 -0500, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-03-03 21:40:42 Re: pg_stop_backup() v2 incorrectly marked as proretset
Previous Message Andres Freund 2022-03-03 21:20:59 Re: [Proposal] Global temporary tables