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