Re: SSI and Hot Standby

On 21.01.2011 03:19, Dan Ports wrote:
>> What I'm still not clear on is why that HS is different. Whatever rules
>> apply on the master must also apply on the standby, immutably. Why is it
>> we need to pass explicit snapshot information from master to standby? We
>> don't do that, except at startup for normal HS. Why do we need that?
>>
>> I hear, but do not yet understand, that the SSI transaction sequence on
>> the master may differ from the WAL transaction sequence. Is it important
>> that the ordering on the master would differ from the standby?
>
> The logical serializable ordering of transactions in SSI doesn't
> necessarily match the commit time ordering (i.e. the WAL sequence). For
> example, with two concurrent transactions, T1 might commit after T2,
> even though it didn't see the changes made by T2 and thus has to be
> considered "earlier".
>
> It doesn't matter whether T1 committed before T2 or the other way
> around, as long as no other transaction can tell the difference. If
> someone saw the changes made by T1 but not those made by T2, they'd see
> T2 as happening before T1, violating serializability. Our SSI code
> ensures that doesn't happen by tracking read dependencies. If it
> detects that such a read is happening, it rolls back one of the
> transactions involved.
>
> Now, if we extend this to hot standby, if T2 commits before T1 on the
> master, it obviously will on the slave too. A transaction run on the
> slave at the right time might be able to see that T2 has happened but
> not T1, which is unserializable. If that transaction had ben run on the
> master, then it would have been detected and something would have been
> rolled back, but the master has no way to know what data is being read
> on the slave.

We have enough information in the standby to reconstruct all writes done
in the master. I gather that's not enough, in order to roll back
read-only transaction T3 on the standby which would see an anomaly, we'd
also need to know what reads T1 and T2 did in the master. Is that correct?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com