Magnus Hagander wrote > Tom Lane wrote: > > =?us-ascii?Q?Tom=20Tom?= <[EMAIL PROTECTED]> 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
