Re: Re: pg_restore fails on Windows - Mailing list pgsql-general

=?us-ascii?Q?Tom=20Tom?= <cobold@seznam.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

pgsql-general by date:

Previous
From: "Roderick A. Anderson"
Date:
Subject: Re: [Q] DNS(bind) ER model
Next
From: "Dot Yet"
Date:
Subject: Horology test failure while compiling PostgreSQL 8.3.3 on Solaris 10 x64