Обсуждение: 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

---

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
PostgreSQL8.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 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

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