Re: WIP patch for parallel pg_dump
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: marcin mank <marcin.mank@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>, Joachim Wieland <joe@mcknight.de>, Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-12-06T21:15:41Z
Lists: pgsql-hackers
marcin mank <marcin.mank@gmail.com> writes: > On Sun, Dec 5, 2010 at 7:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> IIRC, in old discussions of this problem we first considered allowing >> clients to pull down an explicit representation of their snapshot (which >> actually is an existing feature now, txid_current_snapshot()) and then >> upload that again to become the active snapshot in another connection. > Could a hot standby use such a snapshot representation? I.e. same > snapshot on the master and the standby? Hm, that's a good question. It seems like it's at least possibly workable, but I'm not sure if there are any showstoppers. The other proposal of publish-a-snapshot would presumably NOT support this, since we'd not want to ship the snapshot temp files down the WAL stream. However, if you were doing something like parallel pg_dump you could just run the parent and child instances all against the slave, so the pg_dump scenario doesn't seem to offer much of a supporting use-case for worrying about this. When would you really need to be able to do it? regards, tom lane