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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>
Cc: "Daniel Verite" <daniel(at)manitou-mail(dot)org>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "ashutosh(dot)bapat" <ashutosh(dot)bapat(at)2ndquadrant(dot)com>
Subject: Re: A bug when use get_bit() function for a long bytea string
Date: 2020-04-07 20:39:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> It would be easier to get this done if you had addressed any of the
> objections to the patch as given. Integer-overflow handling is still
> missing, and you still are assuming that it's okay to change catalog
> entries in released branches.

Since we are hard upon the feature freeze deadline, I took it on myself
to split this apart. As far as I can see, the only part we really want
to back-patch is the adjustment of the range-limit comparisons in
byteaGetBit and byteaSetBit to use int64 arithmetic, so they don't
go wacko when the input bytea exceeds 256MB. The other changes are
not live bugs because in current usage the estimated result size of
an encoding or decoding transform couldn't exceed 4 times 1GB.
Hence it won't overflow size_t even on 32-bit machines, thus the
check in palloc() is sufficient to deal with overlength values.
But it's worth making those changes going forward, I suppose,
in case somebody wants to deal with longer strings someday.

There were some other minor problems too, but I think I fixed

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-04-07 20:42:10 Re: Improving connection scalability: GetSnapshotData()
Previous Message Alvaro Herrera 2020-04-07 20:36:54 Re: FETCH FIRST clause WITH TIES option