Re: WIP patch for parallel pg_dump

On Mon, Dec 6, 2010 at 2:29 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 06.12.2010 02:55, Robert Haas wrote:
>>
>> On Sun, Dec 5, 2010 at 1:28 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>  wrote:
>>>
>>> I'm wondering if we should reconsider the pass-it-through-the-client
>>> approach, because if we could make that work it would be more general and
>>> it wouldn't need any special privileges.  The trick seems to be to apply
>>> sufficient sanity testing to the snapshot proposed to be installed in
>>> the subsidiary transaction.  I think the requirements would basically be
>>> (1) xmin<= any listed XIDs<  xmax
>>> (2) xmin not so old as to cause GlobalXmin to decrease
>>> (3) xmax not beyond current XID counter
>>> (4) XID list includes all still-running XIDs in the given range
>>>
>>> Thoughts?
>>
>> I think this is too ugly to live.  I really think it's a very bad idea
>> for database clients to need to explicitly know anywhere near this
>> many details about how the server represents snapshots.  It's not
>> impossible we might want to change this in the future, and even if we
>> don't, it seems to me to be exposing a whole lot of unnecessary
>> internal grottiness.
>
> 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. I think it's a whole
lot simpler and cleaner to keep the representation details private to
the server.

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