| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WIP patch for parallel pg_dump |
| Date: | 2010-12-06 15:40:44 |
| Message-ID: | 26498.1291650044@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Dec 6, 2010 at 9:45 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Well, then you need some sort of cross-backend communication, which is
>> always a bit clumsy.
> A temp file seems quite sufficient, and not at all difficult.
"Not at all difficult" is nonsense. To do that, you need to invent some
mechanism for sender and receivers to identify which temp file they want
to use, and you need to think of some way to clean up the files when the
client forgets to tell you to do so. That's going to be at least as
ugly as anything else. And I think it's unproven that this approach
would be security-hole-free either. For instance, what about some other
session overwriting pg_dump's snapshot temp file?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-12-06 15:47:15 | Re: WIP patch for parallel pg_dump |
| Previous Message | Robert Haas | 2010-12-06 15:38:13 | Re: WIP patch for parallel pg_dump |