| From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump: largeobject behavior issues (possible bug) |
| Date: | 2015-04-25 00:02:32 |
| Message-ID: | 553AD998.2070304@commandprompt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/24/2015 03:41 PM, Tom Lane wrote:
> Given that large objects don't have any individual dependencies,
> one could envision fixing this by replacing the individual large-object
> DumpableObjects by a single placeholder to participate in the sort phase,
> and then when it's time to dump that, scan the large objects using a
> cursor and create/print/delete the information separately for each one.
> This would likely involve some rather painful refactoring in pg_dump
> however.
Andrew G mentioned something about using a cursor for the main query
that pulls the info. He said that it wasn't a solution but may be a
bandaid (my words). Is that something we may want to look into as a stop
gap?
>
> regards, tom lane
>
--
The most kicking donkey PostgreSQL Infrastructure company in existence.
The oldest, the most experienced, the consulting company to the stars.
Command Prompt, Inc. http://www.commandprompt.com/ +1 -503-667-4564 -
24x7 - 365 - Proactive and Managed Professional Services!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Hernández Tortosa | 2015-04-25 00:11:43 | Re: Fwd: [GENERAL] 4B row limit for CLOB tables |
| Previous Message | Jim Nasby | 2015-04-24 23:00:53 | Re: Feedback on getting rid of VACUUM FULL |