Ryan Bradetich <[EMAIL PROTECTED]> writes:
> That was the problem. Good job at spotting that Tom. I just successfully
> completed a backup without using the -o
> option to pg_dumpall.
OK, if you need it with -o try the following patch against 7.0.2.
regards, tom lane
Ok- this may be a simple answer, but-
Once the database has been dumped, how do you restore while keeping the original OIDs?
I've used the OID as a unique key that ties records together, and somehow they don't
go back together nicely...
doing a dump with "pg_dumpall -o -c > db.out"
restoring w
Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> -- dumping out the contents of Table 'medusa'
> FATAL 1: Memory exhausted in AllocSetAlloc()
> PQendcopy: resetting connection
> SQL query to du
Ryan Bradetich <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Ryan Bradetich <[EMAIL PROTECTED]> 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 'medus
Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> 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
Ryan Bradetich <[EMAIL PROTECTED]> 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 t
Hello all,
I am having a new problem with pg_dumpall that I have not seen before.
I've been
browsing the documentation and could not find anything related to this
problem. Any
ideas or pointers would greatly be appreciated.
boi260 sanity $ /opt/pgsql/bin/pg_dumpall -v -o | /usr/contrib/bin/gzip
