Search Postgresql Archives

Re: Re: pg_restore fails on Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux