Re: A bug when use get_bit() function for a long bytea string

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"ashutosh(dot)bapat" <ashutosh(dot)bapat(at)2ndquadrant(dot)com>,"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-04-03 08:53:33
Message-ID: 3ae0e84f-1d80-4f98-b36e-235ebcae4ff6@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

movead(dot)li(at)highgo(dot)ca wrote:

> >I believe the formula for the upper limit in the 32-bit case is:
> > (len <= PG_INT32_MAX / 8) ? (len*8 - 1) : PG_INT32_MAX;
>
> >These functions could benefit from a comment mentioning that
> >they cannot reach the full extent of a bytea, because of the size limit
> >on the bit number.
>
> Because the 2nd argument is describing 'bit' location of every byte in bytea
> string, so an int32 is not enough for that. I think the change is nothing
> wrong,
> or I have not caught your means?

In existing releases, the SQL definitions are set_bit(bytea,int4,int4)
and get_bit(bytea,int4) and cannot be changed to not break the API.
So the patch meant for existing releases has to deal with a too-narrow
int32 bit number.

Internally in the C functions, you may convert that number to int64
if you think it's necessary, but you may not use PG_GETARG_INT64
to pick a 32-bit argument.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2020-04-03 08:54:33 Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Previous Message Asif Rehman 2020-04-03 08:45:23 Re: WIP/PoC for parallel backup