From: | Martijn van Oosterhout <kleptog(at)cupid(dot)suninternet(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: disk backups |
Date: | 2000-07-01 13:34:57 |
Message-ID: | 395DF381.28BF3C85@cupid.suninternet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> COPY uses a streaming style of output. To generate INSERT commands,
> pg_dump first does a "SELECT * FROM table", and that runs into libpq's
> suck-the-whole-result-set-into-memory behavior. See nearby thread
> titled "Large Tables(>1 Gb)".
Hmm, any reason why pg_dump couldn't do a
SELECT * from table where 1 = 0
to get the column names and then do a COPY and reformat
the output...
> > Yes, we are using -D, mainly because we've had "issues" with
> > the COPY based export, ie, it won't read the resulting file
> > back. Admittedly this was a while ago now and I havn't checked
> > since.
>
> IIRC that's a long-since-fixed bug. If not, file a bug report so
> we can fix whatever's still wrong...
It may be fixed, but we're still running an old version of
postgres, so it may not be fixed in the version we're using...
> Philip Warner needs alpha testers for his new version of pg_dump ;-).
> Unfortunately I think he's only been talking about it on pghackers
> so far.
What versions does it work on?
--
Martijn van Oosterhout <kleptog(at)cupid(dot)suninternet(dot)com>
http://cupid.suninternet.com/~kleptog/
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-07-02 02:26:11 | Re: disk backups |
Previous Message | Jan Wieck | 2000-07-01 09:33:22 | Re: pg_dumpall and check constraints |