On Fri, 15 Jul 2022 at 10:31, Bruce Momjian wrote:
> for non-Assert builds, ItemPointerGetOffsetNumberNoCheck() and
> ItemPointerGetOffsetNumber() are the same, so I don't see the point to
> making this change. Frankly, I don't know why we even have two
> functions for this. I am guessing ItemPo
On Thu, Jul 14, 2022 at 3:59 PM Tom Lane wrote:
> Even in an assert-enabled build, wouldn't you expect the compiler to
> optimize away the second assertion as unreachable code?
I think that it probably would, even at -O0 (GCC doesn't really allow
you to opt out of all optimizations). I did think
Peter Geoghegan writes:
> The proposal doesn't seem like an improvement. Technically the
> assertion cannot possibly fail here because the earlier assertion
> would always fail instead, so strictly speaking it is redundant -- at
> least right now. That is true. But it seems much more important to
On Thu, Jul 14, 2022 at 3:31 PM Bruce Momjian wrote:
> On Wed, Apr 27, 2022 at 08:04:00PM +0800, Junwang Zhao wrote:
> for non-Assert builds, ItemPointerGetOffsetNumberNoCheck() and
> ItemPointerGetOffsetNumber() are the same, so I don't see the point to
> making this change. Frankly, I don't kno
On Wed, Apr 27, 2022 at 08:04:00PM +0800, Junwang Zhao wrote:
> In function ItemPointerEquals, the ItemPointerGetBlockNumber
> already checked the ItemPointer if valid, there is no need
> to check it again in ItemPointerGetOffset, so use
> ItemPointerGetOffsetNumberNoCheck instead.
>
> Signed-off-
In function ItemPointerEquals, the ItemPointerGetBlockNumber
already checked the ItemPointer if valid, there is no need
to check it again in ItemPointerGetOffset, so use
ItemPointerGetOffsetNumberNoCheck instead.
Signed-off-by: Junwang Zhao
---
src/backend/storage/page/itemptr.c | 4 ++--
1 file
