Re: No buffer space available - Mailing list pgsql-general

From andyk
Subject Re: No buffer space available
Date
Msg-id 45EDB51E.1060700@commandprompt.com
Whole thread Raw
In response to No buffer space available  ("Nik" <XLPizza@gmail.com>)
Responses Re: No buffer space available
Re: No buffer space available
List pgsql-general
Nik wrote:
> I have an SQL file with a set of about 3000 insert statements. This
> file is executed twice from a remote client machine running Windows
> XP. The first time it is executed against a Windows 2003 Server
> running PostgreSQL 8.0. The second time it is executed against a
> Windows 2003 Server running PostgreSQL 8.2. This setup has been in
> place for about a year now and never had any issues.
>
> However, I noticed today that all the file executions fail with
> [nativecode=could not send data to server: No buffer space available
> (0x00002747/10055)] error.
>
> I attempted to run the same file using pgAdmin III version 1.6.2, but
> every time the file is executed the only return in messages pane is
> the colon sign ":". No data is inserted.
>
> I attempted to run the same file using psql.exe and this worked
> without any problems.
>
> I also noticed that if I use less inserts, for example only a few
> hundred, the file executes fine.
>
> What could be the issue?
>
> Thank you.
>
> Nik
>
    This error is returned by libpq, as a reaction on WSANOBUFS error
from Windows Socket System. This means, applications tries to send much
data, and system can't do it the same quickly. Possible, libpq should
handle this error more carefully, and wait until all data will be send
to the server.
    To avoid this problem you can:
1) try to use client software, which is not depends on libpq,
or
2) divide your query into smaller parts,
or
3) use software which parses long queries, separates them into single
SQL commands and then executes this commands one by one.


pgsql-general by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: \set a multılıne varıable
Next
From: "Reuven M. Lerner"
Date:
Subject: Re: Database slowness -- my design, hardware, or both?