On 5/26/2010 4:34 PM, Kevin Grittner wrote:
> Jan Wieck <JanWieck@Yahoo.com> wrote:
>
>> Without this logic, the replication system could not combine
>> multiple origin sessions into one replication session without
>> risking to never find a state, in which it can commit.
>
> 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?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
