Re: fetching bytea (blob) data of 850 MB from psql client failed

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: jitesh tiwari <jitesh120(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: fetching bytea (blob) data of 850 MB from psql client failed
Date: 2022-08-22 10:52:29
Message-ID: CAFBsxsExRqZjvkMNBLgS8D-5BUBG6JYhMsqngy=DB5cZOYBV=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Aug 22, 2022 at 4:35 PM jitesh tiwari <jitesh120(at)gmail(dot)com> wrote:
>
> Hi all,
>
> I have a use case in postgresql where I have inserted 500 rows in a table with 2 columns as described below.
> create table xyz (
> id citext not null primary key,
> col1 bytea
> );
>
> The table has 500 rows and each row has around 850 MB of data. The bytea column data in the row has around 830 to 840 MB of data while citext column data has 10 to to 15 bytes approximately.
> When I try to fetch all rows with a select query or try to fetch a single row with a select statement using the where clause for this table, the Database throws the below error -
>
> VERROR; invalid memory alloc request size 1764311653(File mcxt.c; Line 959;
> Routine palloc; )

The request size is about 2x bigger than 880MB, which is what we would
expect when outputting using the default setting for "bytea_output",
which is "hex". Hex uses two bytes of text to represent each byte:

https://www.postgresql.org/docs/devel/datatype-binary.html

Unfortunately this retrieval problem has been encountered before, but
is not documented that I can see:

https://www.postgresql.org/message-id/flat/13120.1518793109%40sss.pgh.pa.us#81d92e9e7e15975e606bdb349ec573d4

If the data is largely printable ASCII, then one thing to try is
setting "bytea_output" to "escape", if your driver and client can
handle that:

https://www.postgresql.org/docs/devel/runtime-config-client.html#GUC-BYTEA-OUTPUT

If the data is binary and not printable ASCII, then there is no easy
workaround. For this, possibly the "large object" facility could be
useful, or storing the data in a regular file with the path stored in
the database.

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-08-22 13:13:38 Re: BUG #17591: elog(ERROR) cause SharedSnapshotLock deadlock
Previous Message Zhang Mingli 2022-08-22 07:45:11 Re: BUG #17591: elog(ERROR) cause SharedSnapshotLock deadlock