Re: A bug when use get_bit() function for a long bytea string - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: A bug when use get_bit() function for a long bytea string
Date
Msg-id 9087da0f-f048-4cd3-a55c-1c03adea5a02@manitou-mail.org
Whole thread Raw
In response to Re: A bug when use get_bit() function for a long bytea string  (Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>)
Responses Re: A bug when use get_bit() function for a long bytea string  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
    Ashutosh Bapat wrote:

> I think we need a similar change in byteaGetBit() and byteaSetBit()
> as well.

get_bit() and set_bit() as SQL functions take an int4 as the "offset"
argument representing the bit number, meaning that the maximum value
that can be passed is 2^31-1.
But the maximum theorical size of a bytea value being 1 gigabyte or
2^30 bytes, the real maximum bit number in a bytea equals 2^33-1
(2^33=8*2^30), which doesn't fit into an "int4".  As a result, the
part of a bytea beyond the first 256MB is inaccessible to get_bit()
and set_bit().

So aside from the integer overflow bug, isn't there the issue that the
"offset" argument of get_bit() and set_bit() should have been an
int8 in the first place?


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: backup manifests
Next
From: Tom Lane
Date:
Subject: Re: plan cache overhead on plpgsql expression