questions on Linearizable isolation level

[pdeva]

There is some confusion regarding Linearizable isolation level, as described in the docs.

The docs say:

1. To enable it, you must enable HASql

However, it is never defined what 'HASql' is?

2. requires that the cluster-machines clocks are synchronized and do not drift beyond a known boundary

From the VLDB paper, it seems that BLP is using GPS clocks for this.
For the rest of us using AWS, is NTP good enough? if so, what is the performance impact of using NTP here instead of gps clocks?

3. attain Linearizable Consistency, and correctness in the face of network partitions

Does this mean that if a network partition occurs, and Linearizable isolation is not being used, data will become inconsistent? From the answer to #146 I was under assumption that partitions are dealt with properly regardless of transaction isolation level.

4. This isolation level is tested for a subset of sql features

What subset is that?

[mponomar]

1. HASQL
2. NTP is fine. Coherency options. Lease time and renew intervals are set to reasonable values. If your clocks are especially unstable, set the lease times higher and the renew interval lower.
3. Data won't become inconsistent. You may see the side effects of transactions that commit on the node you're connected to, but not yet the majority of the cluster. This becomes a problem if a network splits or the master and several other nodes crash. Most applications don't need to protect themselves from this. If it still worries you, enable durable LSNs.
4. I don't know where that line is from. All statements are supported in snapshot and serializable modes.

[pdeva]

@mponomar regarding 4. I was asking about Linearizable isolation (not snapshot or serializable).

https://bloomberg.github.io/comdb2/transaction_model.html#linearizable-isolation-level

This isolation level is tested for a subset of sql features

The doc says Linearizable isolation doesnt have all sql features tested. So I wanted to know which features are those?

[markhannum]

We don't support linearizable isolation level for stored procedures or across schema changes.

…

On Mon, Jun 19, 2017 at 9:57 PM, pdeva ***@***.***> wrote: @mponomar <https://github.com/mponomar> regarding 4. I was asking about Linearizable isolation (not snapshot or serializable). https://bloomberg.github.io/comdb2/transaction_model.html# linearizable-isolation-level This isolation level is tested for a subset of sql features The doc says Linearizable isolation doesnt have all sql features tested. So I wanted to know which features are those? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APfiUnnmecK12zgMVKGQvrv8CLS_DNSiks5sFycKgaJpZM4N-zyh> .

[pdeva]

or across schema changes

sorry i am a little confused here and this might be a silly question.

By 'across schema changes' in this context, do you mean if i do an 'alter table', that 'alter table' statement is not linearizable?

[markhannum]

I haven't explicitly tested whether or not we remain linearizable during an online schema change in the face of random network partitions- I can't claim that I know that this would work correctly. That being said, this code is very well tested, and works correctly for the loss of nodes during a schema change. If one of the lost nodes happens to be the master, we even have code which will allow the new master to pick-up and continue the schema change where the old master left off. I've found that introducing random network partitions is a much more difficult test to pass.

…

On Mon, Jun 19, 2017 at 10:18 PM, pdeva ***@***.***> wrote: or across schema changes sorry i am a little confused here and this might be a silly question. By 'across schema changes' in this context, do you mean if i do an 'alter table', that 'alter table' statement is not linearizable? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APfiUjq9ZqQcSJVy9LhXn5pjSCjJuOW6ks5sFyvmgaJpZM4N-zyh> .