Re: casting operand to proper type in BlockIdGetBlockNumber - Mailing list pgsql-hackers

From Tom Lane
Subject Re: casting operand to proper type in BlockIdGetBlockNumber
Date
Msg-id 3203868.1646327620@sss.pgh.pa.us
Whole thread Raw
In response to Re: casting operand to proper type in BlockIdGetBlockNumber  (Zhihong Yu <zyu@yugabyte.com>)
Responses Re: casting operand to proper type in BlockIdGetBlockNumber  (Zhihong Yu <zyu@yugabyte.com>)
Re: casting operand to proper type in BlockIdGetBlockNumber  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Zhihong Yu <zyu@yugabyte.com> writes:
> On Thu, Mar 3, 2022 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Oh, I misread this as a compile-time warning, but it must be from ASAN.
>> Was the test case one of your own, or just our normal regression tests?

> The Jenkins test is ported from contrib/postgres_fdw/sql/postgres_fdw.sql -
> so theoretically PG would see the same error for clang12 on Alma.

Hmph.  I tried enabling -fsanitize=undefined here, and I get some
complaints about passing null pointers to memcmp and the like, but
nothing about this shift (tested with clang 12.0.1 on RHEL8 as well
as clang 13.0.0 on Fedora 35).  What compiler switches are being
used exactly?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Next
From: Stephen Frost
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15