Apple open-sources FoundationDB • Hacker News Board

Re: Apple open-sources FoundationDB

#451

Post by cakoose » Mon, Apr 30, 2018, 9:45 AM UTC

benmmurphy wrote: post #446

polskibus wrote: post #415

Earlier quoted context omitted.

as far as I know SSI as implemented in Postgresql, aborts the way you describe, as per https://drkp.net/papers/ssi-vldb12.pdf

postgresql is not strictly serializable/externally consistent for example this will commit under serializable: create table counters(counter int); insert into counters(counter) values(1); BEGIN TRANSACTION ISOLATION LEVEL serializable; select sum(counter) from counters; /* insert sum into counters. wait until committing next transaction before executing the insert */ insert into counters(counter) values(1); COMMIT; /…

Even without external consistency, a I'm having trouble coming up with an ordering of the transactions that yields [1], [1, 10], [1, 1, 10].

Is that because PostgreSQL's "SERIALIZABLE" doesn't follow the "some serial order" definition? Or maybe I'm missing something else?

Re: Apple open-sources FoundationDB

#452

Post by anarazel » Mon, Apr 30, 2018, 7:44 PM UTC

cakoose wrote: post #451

benmmurphy wrote: post #446

Earlier quoted context omitted.

postgresql is not strictly serializable/externally consistent for example this will commit under serializable: create table counters(counter int); insert into counters(counter) values(1); BEGIN TRANSACTION ISOLATION LEVEL serializable; select sum(counter) from counters; /* insert sum into counters. wait until committing next transaction before executing the insert */ insert into counters(counter) values(1); COMMIT; /…

Even without external consistency, a I'm having trouble coming up with an ordering of the transactions that yields [1], [1, 10], [1, 1, 10]. Is that because PostgreSQL's "SERIALIZABLE" doesn't follow the "some serial order" definition? Or maybe I'm missing something else?

Well, benmmurphy isn't talking about serializability (some correct ordering exists), but strict serializabilty (roughly: at least one correct ordering corresponds to wall clock order). PG does have the former, but not the latter.

Re: Apple open-sources FoundationDB

#453

Post by cakoose » Tue, May 01, 2018, 5:16 AM UTC

anarazel wrote: post #452

cakoose wrote: post #451

Earlier quoted context omitted.

Even without external consistency, a I'm having trouble coming up with an ordering of the transactions that yields [1], [1, 10], [1, 1, 10]. Is that because PostgreSQL's "SERIALIZABLE" doesn't follow the "some serial order" definition? Or maybe I'm missing something else?

Well, benmmurphy isn't talking about serializability (some correct ordering exists), but strict serializabilty (roughly: at least one correct ordering corresponds to wall clock order). PG does have the former, but not the latter.

Huh? The example is for PostgreSQL's "serializable" isolation level, and that's what I'm confused about.

Serializability should ensure that the outcome is equivalent to some serial execution. What serial execution of those five transactions yields [1], [1, 10], [1, 1, 10]?

But also, I just read that prior to PostgreSQL 9.1 (released in 2011), the "serializable" isolation level was actually just snapshot isolation (now called "repeatable read"). So maybe that's what benmmurphy is referring to?