Tom Lane wrote: > Simon Riggs writes: >> On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote: >>> The idea is that whenever we see a valid snapshot which would >>> yield a truly serializable view of the data for a READ ONLY >>> transaction, we add a WAL record with that snapshot information. > >> You haven't explained why this approach is the way forwards. What >> other options have been ruled out, and why. The above approach >> doesn't sound particularly viable to me. > > I'm pretty concerned about the performance implications, too. In > particular that sounds like you could get an unbounded amount of > WAL emitted from a *purely read only* transaction flow. Which is > not going to fly. Ah, coming back to this and re-reading, I think I see the point of confusion. The technique we're suggesting is based on the fact that the *standby* is read only. The flow of information about snapshots (which might be done as actual snapshots with xid values, or possibly as marker records saying when a candidate snapshot is being considered and when the last one has been found acceptable) would be from the master *to* the standby, based on *read write transactions on the master*. They would be informing the slave of what would be a snapshot guaranteed not to see a serialization anomaly to a read only transaction. As I mentioned in another email, we might want to throttle this. My thinking was that we could start a timer on capturing a snapshot, and continue to gather new ones as they become available. When you hit the timer limit (maybe 100ms?) you send the latest snapshot, if you have a new one; otherwise you keep trying and send one as soon as you get it. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
