Re: A bug when use get_bit() function for a long bytea string
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Ashutosh Bapat" <ashutosh.bapat@2ndquadrant.com>
Cc: "movead.li@highgo.ca" <movead.li@highgo.ca>,"pgsql-hackers"
<pgsql-hackers@lists.postgresql.org>
Date: 2020-03-27T17:58:44Z
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
Commits
-
Adjust bytea get_bit/set_bit to cope with bytea strings > 256MB.
- e40c4d4914fd 9.6.18 landed
- dbb121038c74 9.5.22 landed
- 889786e0e8c1 10.13 landed
- 6e6b74a206c3 12.3 landed
- 5d79fc60c57d 11.8 landed
-
Adjust bytea get_bit/set_bit to use int8 not int4 for bit numbering.
- 26a944cf29ba 13.0 landed