OK, so here I should - maybe - look around the sockets. Hmm. Well, in the case of my experiments we are talking about
Unixsockets, as I am only connecting locally to the server (not real networking involved). Are there any ideas, where
sucha Unix Socket could impose such extreme buffering ??? And can/could I control its behavior at all?? (or would it be
athing, which can only be controlled from C-Code ... which would fall back to PostgreSQL as the initiator).
Andras Fabian
-----Ursprüngliche Nachricht-----
Von: Craig Ringer [mailto:craig@postnewspapers.com.au]
Gesendet: Dienstag, 13. Juli 2010 12:51
An: Andras Fabian
Cc: pgsql-general@postgresql.org
Betreff: Re: AW: AW: AW: [GENERAL] PG_DUMP very slow because of STDOUT ??
On 13/07/2010 6:26 PM, Andras Fabian wrote:
> Wait, now, here I see some correlation! Yes, it seems to be the memory! When I start my COPY-to-STDOUT experiment I
hadsome 2000 MByte free (well ,the server has 24 GByte ... maybe other PostgreSQL processes used up the rest). Then, I
couldmonitor via "ll -h" how the file nicely growed (obviously no congestion), and in parallel see, how "free -m" the
"free"memory went down. Then, it reached a level below 192 MByte, and congestion began. Now it is going back and forth
around118-122-130 ... Obviously the STDOUT thing went out of some memory resources.
> Now I "only" who and why is running out, and how I can prevent that.
> Could there be some extremely big STDOUT buffering in play ????
Remember, "STDOUT" is misleading. The data is sent down the network
socket between the postgres backend and the client connected to that
backend. There is no actual stdio involved at all.
Imagine that the backend's stdout is redirected down the network socket
to the client, so when it sends to "stdout" it's just going to the
client. Any buffering you are interested in is in the unix or tcp/ip
socket (depending on how you're connecting), in the client, and in the
client's output to file/disk/whatever.
--
Craig Ringer
