Re: WIP patch for parallel pg_dump

On Mon, Dec 6, 2010 at 9:45 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 06.12.2010 14:57, Robert Haas wrote:
>>
>> On Mon, Dec 6, 2010 at 2:29 AM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>>>
>>> The client doesn't need to know anything about the snapshot blob that the
>>> server gives it. It just needs to pass it back to the server through the
>>> other connection. To the client, it's just an opaque chunk of bytes.
>>
>> I suppose that would work, but I still think it's a bad idea.  We made
>> this mistake with expression trees.  Any oversight in the code that
>> validates the chunk of bytes when it (or a modified version) is sent
>> back to the server turns into a security hole.
>
> True, but a snapshot is a lot simpler than an expression tree. It's pretty
> much impossible to plug all the holes in the expression-tree reading
> functions, and keep them hole-free in the future. The expression tree format
> is constantly in flux. A snapshot, however, is a fairly isolated small data
> structure that rarely changes.

I guess. It still seems far too much like exposing the server's guts
for my taste. It might not be as bad as the expression tree stuff,
but there's nothing particularly good about it either.

>>  I think it's a whole
>> lot simpler and cleaner to keep the representation details private to
>> the server.
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company