Re: WIP patch for parallel pg_dump

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.

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