From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Tom <cobold(at)seznam(dot)cz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_restore fails on Windows |
Date: | 2008-08-20 10:00:12 |
Message-ID: | 48ABEB2C.7080400@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Tom wrote:
> Magnus Hagander wrote
>> Tom Lane wrote:
>>> =?us-ascii?Q?Tom=20Tom?= <cobold(at)seznam(dot)cz> writes:
>>>> Magnus Hagander wrote:
>>>>> Attached is a pg_restore.exe off CVS tip today, which should include the
>>>>> patch. Please try this one.
>>>> I tested the restore using the provided pg_restore.exe. The output is:
>>>> pg_restore: [archiver (db)] could not execute query: could not send data to
>> server: No buffer space available (0x00002747/10055)
>>> According to
>>> http://support.microsoft.com/kb/201213
>>> this is an acknowledged bug that's been broken since Windows 95, so
>>> I suppose we should conclude that M$ is unwilling or incompetent to
>>> fix it.
>> Yup, I was just reading that one when I saw your email. I finally got
>> around to building a libpq with this change in it - attached here. Tom
>> (not Lane), can you test this please?
>>
>> It shouldn't be this one really, since it doesn't list any modern
>> Windows versions as having this issue, but it's worth a try.
>
> Tested. The restore comes through successfuly with the patched libpq.
> So I take it that it's caused by the MS issue. Again, we are using WinXP Professional SP2. Perhaps the
> system buffer space was _increased_ in XP (10MB comes through easily),
> still if the block is too large, it occurs (speculation).
Yes, that sounds quite likely. They fixed the symptoms, but not the
underlying problem.
> Since I don't know the implementation details of the patch I'd like to ask:
> 1.This is not official patch, didn't pass the review/test cycle; do you think that it can be used in the
> production environment (any side effects or so..)? If not, is the patch due for a next version?
I plan to apply it to HEAD and supported back-branches (8.3 and 8.2) now
that you have verified that it works, so it will be in the next
versions. The only potential side-effect is that it will be slightly
slower on packets >64kb, but I doubt that's even measurable in most cases.
So yes, it should be safe to use in production.
> 2.Our production PG version is 8.1.3. For some reasons it is not possible to upgrade to the LATEST;
> I tested the libpq also on this version and it worked. Is it OK? I mean, did it worked by chance or the library
> API & contracts didn't change between this version and latest?
Note that libpq is only the *client* side. There is no patch necessary
on the server. It might be easier to upgrade than the server?
Did you test it with the pg_restore that I sent, or with the one from
8.1? The pg_restore I sent was for HEAD, as well as the libpq I sent, so
you shouldn't use those in production long-term.
For binaries, we don't provide backpatches for 8.1 any more (it's not a
supported platform on Windows!), but you might be able to use the latest
8.2 libpq with the 8.1 pg_restore - you'll have to try that once the
release is eventually out.
Or you can just apply the patch to the latest 8.1 libpq and build it
yourself, of course. I think it should apply just fine.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Roshni Mani | 2008-08-20 10:13:54 | Sequences using libpqxx |
Previous Message | Robert Gravsjö | 2008-08-20 08:18:18 | Re: What's size of your PostgreSQL Database? |