From: Tom Lane <tgl@sss.pgh.pa.us>
To: "movead.li@highgo.ca" <movead.li@highgo.ca>
cc: "Daniel Verite" <daniel@manitou-mail.org>,
        pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
        "ashutosh.bapat" <ashutosh.bapat@2ndquadrant.com>
Subject: Re: A bug when use get_bit() function for a long bytea string
In-reply-to: <9172.1586271763@sss.pgh.pa.us>
References: <3ae0e84f-1d80-4f98-b36e-235ebcae4ff6@manitou-mail.org>,
 <2020040709294706977061@highgo.ca> <2020040713393391866468@highgo.ca>
 <9172.1586271763@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 07 Apr 2020 11:02:43 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17603.1586291952.1@sss.pgh.pa.us>
Date: Tue, 07 Apr 2020 16:39:12 -0400
Message-ID: <17604.1586291952@sss.pgh.pa.us>
Precedence: bulk

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
everything.

			regards, tom lane