Re: Re: pg_restore fails on Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Tom <cobold(at)seznam(dot)cz>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Re: pg_restore fails on Windows
Date: 2008-08-15 14:48:22
Message-ID: 21627.1218811702@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?us-ascii?Q?Tom=20Tom?= <cobold(at)seznam(dot)cz> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dot Yet 2008-08-15 14:50:48 Horology test failure while compiling PostgreSQL 8.3.3 on Solaris 10 x64
Previous Message Roderick A. Anderson 2008-08-15 14:48:19 Re: [Q] DNS(bind) ER model