Jan Wieck <JanWieck@Yahoo.com> wrote:
> On 5/26/2010 4:34 PM, Kevin Grittner wrote:
>> My latest idea for handling this in WAL-based replication
>> involves WAL-logging information about the transaction through
>> which a the committing transaction makes it safe to view. There
>> are a few options here at the detail level that I'm still
>> thinking through. The idea would be that the xmin from read-only
>> queries on the slaves might be somewhere behind where you would
>> expect based on transactions committed. (The details involve
>> such things as where non-serializable transactions fall into the
>> plan on both sides, and whether it's worth the effort to
>> special-case read-only transactions on the master.)
>>
>> I can't say that I'm 100% sure that some lurking detail won't
>> shoot this technique down for HS, but it seems good to me at a
>> conceptual level.
>
> Without simulating multiple simultaneous transactions during
> playback, how are you going to manage that the tuples, already
> inserted on behalf of the ongoing master transactions, disappear
> when they abort on the master?
When do writes ever become visible to a snapshot without having been
committed? I'm not talking about changing that in any way. I'm
talking about deferring visibility of committed transactions until
they can be viewed without risking serialization anomalies. This
requires, at a minimum, that any concurrent serializable
transactions which are not read-only have completed.
(Perhaps I'm not understanding your question....)
-Kevin
