On Mon, Aug 3, 2020 at 05:39:47PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-03, Bruce Momjian wrote:
>
> > So, the character and octet length is 600 million, but on output, that
> > will be expanded, and both SELECT and pg_dump fail. I also can't see
> > how to improve the error message since
On 2020-Aug-03, Bruce Momjian wrote:
> So, the character and octet length is 600 million, but on output, that
> will be expanded, and both SELECT and pg_dump fail. I also can't see
> how to improve the error message since it happens so low in the stack.
I think you'll find commits fa2fa9955280
On Mon, Aug 3, 2020 at 04:44:38PM -0400, Joe Conway wrote:
> It is easier to reproduce than that:
>
> select repeat('x',6)::bytea;
> ERROR: invalid memory alloc request size 120003
>
> select octet_length(repeat('x',6)::bytea);
> octet_length
> --
>
On 8/3/20 4:20 PM, Bruce Momjian wrote:
> On Fri, Jul 31, 2020 at 10:13:48AM +0500, Andrey M. Borodin wrote:
>> Hi Anna!
>>
>> > 23 мая 2018 г., в 20:33, Anna Akenteva
>> > написал(а):
>> >
>> >
>> > Some time ago I've encountered a problem with the bytea type: we can't
>> > SELECT
>> >
On Fri, Jul 31, 2020 at 10:13:48AM +0500, Andrey M. Borodin wrote:
> Hi Anna!
>
> > 23 мая 2018 г., в 20:33, Anna Akenteva
> > написал(а):
> >
> >
> > Some time ago I've encountered a problem with the bytea type: we can't
> > SELECT
> > bytea strings whose textual representation is too big
Hi Anna!
> 23 мая 2018 г., в 20:33, Anna Akenteva написал(а):
>
>
> Some time ago I've encountered a problem with the bytea type: we can't SELECT
> bytea strings whose textual representation is too big to fit into
> StringInfoData.
> And as a side effect, pg_dump refuses to dump tables with
