Re: [DOCS] Let's document a bytea bug

Hi Anna!

> 23 мая 2018 г., в 20:33, Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru> написал(а):
>
>
> 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 big bytea strings.
>
> It's a bug, it's pretty confusing, but it seems like there's no pretty way
> to fix it so far. Here's a link to a recent discussion on the issue:
> https://www.postgresql.org/message-id/flat/c8bdf802d41ec37003ec3b726db79428(at)postgrespro(dot)ru#c8bdf802d41ec37003ec3b726db79428@postgrespro.ru
>
> Since it won't be fixed anytime soon, I thought it could be worth documenting.
> Attaching a patch for the documentation: I added some text to the "Binary Data Types"
> part where I tried to describe the issue and to explain how to deal with it.
>
> My patch in plain text (for convenience):
>
> It is not recommended to use bytea strings whose textual representation
> exceeds 1GB, as it may not be possible to SELECT them due to output size
> limitations. Consequently, a table containing such big strings cannot be
> properly processed by pg_dump, as pg_dump will try to SELECT these values from the
> table and fail. The exact size limit advised for bytea strings depends on their
> content, the external format and encoding that you are using, the context in
> which they will be selected. The general rule is that when you use SELECT,
> the returned tuple should not exceed 1GB. Although even if SELECT does not
> work, you can still retrieve big bytea strings using COPY in binary format.

Thanks for this message. It took me a while to find out what was the problem.
+1 for documenting this, maybe even with exact error like
[ 2020-07-30 01:20:32.248 MSK pg_dump - 10.3.3.30,XX000 ]:ERROR: invalid memory alloc request size 1472599557
It's really really scary. My first feeling was that it's TOAST corruption.

Best regards, Andrey Borodin.