Обсуждение: pg_dump throws no buffer space available error

I can only reproduce this error on windows 2000, on all other
operating systems it works fine. Sometimes I see "No buffer
space available error", other times I see "Socket not open
error".

In the database, besides other tables we have one table that
contains bytea type columns, we see the above error when the
copy command is executed for this table.

I put in some print statements in socket.c, it looks like the
pgwin32_recv() call times out waiting to read from the send
buffer. Since the execution of the query at the server for the
table containing bytea columns takes long time, there is nothing
at the server side buffer to send to the recv side which just
times out and throws socket not open error. I do not understand
the inner working of the recv() and send() data transfer. Can
someone explain it?. Also has any one else has seen this
problem?

Thanks.


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

I modified pg_dump.c and aded a sleep of 1000 micro sec in the
loop for copying data and it fixed the problem. It looks like
for slower machines when it comes to reading larger tables,
pg_dump finds no data to read in new lines and assumes EOL while
there is still data to be dumped, as a result PQendcopy() throws
error. THROTTLE comments in pg_dump were helpful. Any thoughts.

Thanks.

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

Vishal Dixit wrote:
> I modified pg_dump.c and aded a sleep of 1000 micro sec in the
> loop for copying data and it fixed the problem. It looks like
> for slower machines when it comes to reading larger tables,
> pg_dump finds no data to read in new lines and assumes EOL while
> there is still data to be dumped, as a result PQendcopy() throws
> error. THROTTLE comments in pg_dump were helpful. Any thoughts.

What operating system is this?  It sounds broken.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

This is Windows 2000 Server, 2.00GHz Pentium.

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

Vishal Dixit <vishal_d@ureach.com> writes:
> I modified pg_dump.c and aded a sleep of 1000 micro sec in the
> loop for copying data and it fixed the problem. It looks like
> for slower machines when it comes to reading larger tables,
> pg_dump finds no data to read in new lines and assumes EOL while
> there is still data to be dumped, as a result PQendcopy() throws
> error. THROTTLE comments in pg_dump were helpful. Any thoughts.

This is hard to believe.  If you're running out of network buffers,
slowing down the data-consuming process ought to make things worse not
better.  pg_dump doesn't have any direct way of throttling the backend's
output; that happens when the network queue is full and the kernel
starts blocking the backend's send() requests.  I would have taken your
problem to suggest that Windows 2003 doesn't cope very well with a full
network queue.

            regards, tom lane