Re: Problem with pg_dumpall

Tom Lane wrote:

> Ryan Bradetich <ryan_bradetich(at)hp(dot)com> writes:
> > Tom Lane wrote:
> >> Ryan Bradetich <ryan_bradetich(at)hp(dot)com> writes:
> >>>> -- dumping out the contents of Table 'medusa'
> >>>> FATAL 1: Memory exhausted in AllocSetAlloc()
> >>>> PQendcopy: resetting connection
> >>>> SQL query to dump the contents of Table 'medusa' did not execute
> >>>> correctly. After we read all the table contents from the backend,
> >>>> PQendcopy() failed. Explanation from backend: 'FATAL 1: Memory
> >>>> exhausted in AllocSetAlloc()
> >>>> '.
> >>>> The query was: 'COPY "medusa" WITH OIDS TO stdout;
>
> Now that I look at it, it appears that COPY WITH OIDS leaks the memory
> used for the string representation of the OIDs. That'd probably cost
> you 32 bytes or so of backend memory per row --- which you'd get back
> at the end of the COPY, but small comfort if you ran out before that.
>
> Is the table large enough to make that a plausible explanation?
>
> regards, tom lane

Tom,

This table is very large so that could be the problem.

Here are the startup parameters I am using (in case it matters):
-B 1024
-S
-o -F
-o -o /home/postgres/nohup.out
-i
-p 5432
-D/data08

nohup su - postgres -c "/opt/pgsql/bin/postmaster -B 1024 -S -o \"-F\" -o
\"-o /home/postgres/nohup.out\" -i -p 5432 -D/data08"
procman=# select count(*) from medusa;
count
---------
6986499
(1 row)

FYI:

That was the problem. Good job at spotting that Tom. I just successfully
completed a backup without using the -o
option to pg_dumpall.

Thanks again for the help!

- Ryan

--
Ryan Bradetich
AIT Operations
Unix Platform Team