We may need other means to ensure that the snapshot is available on the slave. It could be a bit too early to use the snapshot on the slave depending upon the delay of WAL replay. ---------- Koichi Suzuki
2010/12/7 Tom Lane <t...@sss.pgh.pa.us>: > marcin mank <marcin.m...@gmail.com> writes: >> On Sun, Dec 5, 2010 at 7:28 PM, Tom Lane <t...@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 > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
