From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Ashutosh Bapat" <ashutosh(dot)bapat(at)2ndquadrant(dot)com> |
Cc: | "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>,"pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: A bug when use get_bit() function for a long bytea string |
Date: | 2020-03-27 17:58:44 |
Message-ID: | 9087da0f-f048-4cd3-a55c-1c03adea5a02@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-03-27 18:01:44 | Re: plan cache overhead on plpgsql expression |
Previous Message | Robert Haas | 2020-03-27 17:53:54 | Re: backup manifests |