Thread: 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