Re: Re: pg_restore fails on Windows

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).

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?

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?

>
> One other thing not asked here btw - is this over SSL or not?

SSL is out of game, we are not using it.

>
>
> > Possibly the best workaround is something like
> >
> > + #ifndef WIN32
> > sent = pqsecure_write(conn, ptr, len);
> > + #else
> > + /* Windows tends to fail on large sends, see KB 20213 */
> > + sent = pqsecure_write(conn, ptr, Min(len, 65536));
> > + #endif
> >
> > in pqSendSome(). The backend seems to not be subject to a similar
> > problem because it's already filtering its output through a limited-size
> > buffer.
>
> The other option would be to turn off buffering in the sockets per the
> third bulletpoint. But I think that's an even uglier solution.
>

Regards, Tomas