=?us-ascii?Q?Tom=20Tom?= <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Can you set up a reproducible test-case that doesn't involve your data,
> - test row was inserted using the Java client code
> INSERT INTO hibtableattachmentxmldata VALUES (?,?,?)
> where value 1 is "1111"
> value 2 is 25MB (i.e. 1024*1024*25) long text of char 'F' (0x46)
> value 3 is 25MB (i.e. 1024*1024*25) long byte array filled with values of 5
> (0x5)
Hmm. So allowing for escaping of the bytea values, this line is going
to be somewhere around 150MB in text form --- and because you used
--inserts rather than COPY mode, it will have to be sent in a single
message.
I think it's pretty obvious that what's happening is we're failing to do
that and then not recovering nicely at all. A look at the pg_dump code
says the error message is coming from here
res = PQexec(conn, qry->data);
if (!res)
die_horribly(AH, modulename, "%s: no result from server\n", desc);
and a look at the libpq code suggests that PQexec will return a NULL on
any send failure, which isn't part of its contract either. So we've
got robustness issues on both sides of that API :-(
Of course the larger issue is why it's failing --- 150MB doesn't seem
like that much for a modern machine. I suspect that PQerrorMessage()
would tell us something useful, but pg_restore isn't letting us see it.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
