Re: WIP patch for parallel pg_dump - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: WIP patch for parallel pg_dump
Date
Msg-id 4CFC90C0.6000001@enterprisedb.com
Whole thread Raw
In response to Re: WIP patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 06.12.2010 02:55, Robert Haas wrote:
> On Sun, Dec 5, 2010 at 1:28 PM, Tom Lane<tgl@sss.pgh.pa.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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Timeout and wait-forever in sync rep
Next
From: Heikki Linnakangas
Date:
Subject: Re: Timeout and wait-forever in sync rep