Can't make backup (again)
Hi,
Some days ago we were having problems running pg_dump (v. 8.2.5.7260) from Windows XP SP2 to a database in a sever PostgreSQL 8.2.5 on amd64-portbld-freebsd6.2.
We thought the problem was solved but we are having problems again.
Now we got an error:
"cannot allocate memory for input buffer"
The command was: "COPY public.sipat00 (sipasede, ... ) TO stdout;
�Is this a memory problem? �From server (FreeBSD) or from client PC (Windows XP)?
Thanks
Sebasti�n
Sebasti�n Baioni
http://www.acomplejados.com.ar
http://www.extremista.com.ar
http://www.coolartists.com.ar
---------------------------------
Yahoo! Encuentros
Ahora encontrar pareja es mucho m�s f�cil, prob� el nuevo Yahoo! Encuentros.
Visit� http://yahoo.cupidovirtual.com/servlet/NewRegistration
Sebastián Baioni wrote:
Hi,
Some days ago we were having problems running pg_dump (v. 8.2.5.7260) from Windows XP SP2 to a database in a sever PostgreSQL 8.2.5 on amd64-portbld-freebsd6.2.
We thought the problem was solved but we are having problems again.
Now we got an error:
"cannot allocate memory for input buffer"
The command was: "COPY public.sipat00 (sipasede, ... ) TO stdout;¿Is this a memory problem?
Well, yes you can't allocate memory.
¿From server (FreeBSD) or from client PC (Windows XP)?
Did you see the error on the client PC or the server?
What do the server logs show?
What was the memory usage on the client when this happened?
--
Richard Huxton
Archonet Ltd
--- Richard Huxton <dev@archonet.com> escribi�:
Sebasti�n Baioni wrote:
Hi,
Some days ago we were having problems running pg_dump (v. 8.2.5.7260) from Windows XP SP2 to adatabase in a sever PostgreSQL 8.2.5 on amd64-portbld-freebsd6.2.
We thought the problem was solved but we are having problems again.
Now we got an error:
"cannot allocate memory for input buffer"
The command was: "COPY public.sipat00 (sipasede, ... ) TO stdout;�Is this a memory problem?
Well, yes you can't allocate memory.
�From server (FreeBSD) or from client PC (Windows XP)?
Did you see the error on the client PC or the server?
What do the server logs show?
What was the memory usage on the client when this happened?--
Richard Huxton
Archonet Ltd
The error was in the client PC, the command we used in a command line was: "C:\Program
files\pgAdmin III\1.8\pg_dump.exe" -h mihost -p 5432 -U miuser -F c -v -b -f "C:\back\db.backup"
db
I contacted the Admin and told me there was no erros nor in the postgresql log nor in the server
log.
I don't know the memory usage on the client, I'll try to repeat the error and check it.
Thank you
Sebasti�n
Yahoo! Encuentros.
Ahora encontrar pareja es mucho m�s f�cil, prob� el nuevo Yahoo! Encuentros http://yahoo.cupidovirtual.com/servlet/NewRegistration
--- Sebasti�n Baioni <sebaioni-postgresql@yahoo.com.ar> escribi�:
--- Richard Huxton <dev@archonet.com> escribi�:Sebasti�n Baioni wrote:
Hi,
Some days ago we were having problems running pg_dump (v. 8.2.5.7260) from Windows XP SP2 toa
database in a sever PostgreSQL 8.2.5 on amd64-portbld-freebsd6.2.
We thought the problem was solved but we are having problems again.
Now we got an error:
"cannot allocate memory for input buffer"
The command was: "COPY public.sipat00 (sipasede, ... ) TO stdout;�Is this a memory problem?
Well, yes you can't allocate memory.
�From server (FreeBSD) or from client PC (Windows XP)?
Did you see the error on the client PC or the server?
What do the server logs show?
What was the memory usage on the client when this happened?--
Richard Huxton
Archonet LtdThe error was in the client PC, the command we used in a command line was: "C:\Program
files\pgAdmin III\1.8\pg_dump.exe" -h mihost -p 5432 -U miuser -F c -v -b -f "C:\back\db.backup"
db
I contacted the Admin and told me there was no erros nor in the postgresql log nor in the server
log.
I don't know the memory usage on the client, I'll try to repeat the error and check it.Thank you
Sebasti�n
I forgot to tell that the error was seen on the client but it was a response from the server:
pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer
pg_dump: El comando es: COPY public.sipat00 (sipasede, ...) TO stdout;
pg_dump: *** se abort� por un error
*Mensaje de error del servidor = Server's Error Message
*El comando es: The command is
*se abort� por un error: it was aborted because an error.
Los referentes m�s importantes en compra/ venta de autos se juntaron:
Demotores y Yahoo!
Ahora comprar o vender tu auto es m�s f�cil. Vist� ar.autos.yahoo.com/
Sebastián Baioni wrote:
I contacted the Admin and told me there was no erros nor in the
postgresql log nor in the server log.
I forgot to tell that the error was seen on the client but it was a
response from the server: pg_dump: Mensaje de error del servidor:
cannot allocate memory for input buffer pg_dump: El comando es: COPY
public.sipat00 (sipasede, ...) TO stdout; pg_dump: *** se abort¾ por
un error*Mensaje de error del servidor = Server's Error Message *El comando
es: The command is *se abortó por un error: it was aborted because an
error.
If it is something server-side then there should be something in your
server logs.
However, if you're taking a backup, I would expect the input buffer to
be growing on the client rather than the server.
I think the Server's error message is "abortó por un error", the error
being out-of-memory on your client.
--
Richard Huxton
Archonet Ltd
=?iso-8859-1?q?Sebasti=E1n=20Baioni?= <sebaioni-postgresql@yahoo.com.ar> writes:
I forgot to tell that the error was seen on the client but it was a response from the server:
pg_dump: Mensaje de error del servidor: cannot allocate memory for input buffer
pg_dump: El comando es: COPY public.sipat00 (sipasede, ...) TO stdout;
pg_dump: *** se abort� por un error
No, that error text only appears in libpq, so it's happening on the
client side --- pg_dump just doesn't know the difference between an
error sent from the server and one generated within libpq.
My guess is that there's some extremely wide row(s) in your database.
The client-side libpq has to be able to buffer the widest row during
a COPY, and your client machine doesn't seem to be up to the task...
regards, tom lane