Comment 5 for bug 1277053

On Feb 6, 2014, at 8:44 AM, Alex Yurchenko <email address hidden> wrote:

> 1) causal wait is part of trans_begin() method, so you can always
> establish a proper read view. The fact that trans_begin() is not called
> on autocommit writes suggests (to me) that there are reasons why
> autocommit writes are supposed to be treated somewhat differently.

Hum, I thought causal_reads were literally just finding all SELECTs. Are you saying causal_reads are always in effect for explicit transactions? With or without wsrep_causal_reads=1?

>
> 2) we would rather rely on certification to detect a conflict/out-of-
> date write, rather than on dumb wait.

> The problem comes out of late
> INSERTS - if you don't have a row, you can't detect a conflict (we don't
> even have anything to replicate, since the write was ineffective). As
> such it touches only UPDATEs and DELETEs. (INSERTs a) can be resolved by
> certificaiton, b) it is very unlikely use case that you will be
> inserting the same PK because of stale data (only if you have auto
> increment control turned off))
>
> - the latter consideration brings us to an interesting point: we need a
> mask to specify events that we want to do causal wait. Perhaps we should
> introduce
>
> wsrep_causal_wait = <mask> (1 - SELECT, SHOW, BEGIN, 2 - UPDATE/DELETE,
> 4 - INSERT)
>
> wsrep_causal_reads=ON would be equivalent to wsrep_causal_wait=1

So was SHOW and BEGIN (and I assume START TRANSACTION) always part of causal_reads? Why SHOW?

Any command in autocommit=0 will start a transaction I think — would that be covered by wsrep_causal_wait=1? The extra masks are only for autocommit=1?

Jay Janssen
http://about.me/jay.janssen