Re: WIP patch for parallel pg_dump

On 12/05/2010 08:55 PM, 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.
>
> How about just pg_publish_snapshot(), returning a token that is only
> valid until the end of the transaction in which it was called, and
> pg_subscribe_snapshot(token)? The implementation can be that the
> publisher writes its snapshot to a temp file and returns the name of
> the temp file, setting an at-commit hook to remove the temp file. The
> subscriber reads the temp file and sets the contents as its
> transaction snapshot. If security is a concern, one could also save
> the publisher's role OID to the file and require the subscriber's to
> match.

Why not just say give me the snapshot currently held by process nnnn?

And please, not temp files if possible.

cheers

andrew