Re: In-place updates and serializable transactions

On Thu, Nov 15, 2018 at 3:09 AM Kevin Grittner <kgrittn@gmail.com> wrote:
>
> On Wed, Nov 14, 2018 at 5:43 AM Joshua Yanovski
> <joshua.yanovski@gmail.com> wrote:
>
> > This is only a personal anecdote, but from my own experience with serializability, this sort of blind update isn't
oftencontended in realistic workloads. 
>
> > So, if this only affects transactions with blind updates, I doubt it will cause much pain in real workloads (even
thoughit might look bad in benchmarks which include a mix of blind writes and rmw operations).  Particularly if it only
happensif you explicitly opt into zheap storage. 
>
> I agree with all of that, but will be very interested in what
> failures, if any, kick out from the "isolation" test set when all
> tables are created using zheap.  I added all the common failure
> patterns I had seen to that set, and other have filled in some corner
> cases I missed since then, so if everything there passes I would not
> worry about it at all.  If we do see some failures, we can take
> another look to see whether any action is needed.
Thanks Kevin for your explanation. The isolation test suits are really
helpful for testing serializable test scenarios for zheap.

The test multiple-row-versions is failing because of the
above-discussed scenario. I've attached the regression diff file and
the result output file for the same. Here is a brief summary of the
test w.r.t. heap:

Step 1: T1-> BEGIN; Read FROM t where id=1000000;
Step 2: T2-> BEGIN; UPDATE t where id=1000000; COMMIT; (creates T1->T2)
Step 3: T3-> BEGIN; UPDATE t where id=1000000; Read FROM t where id=500000;
Step 4: T4-> BEGIN; UPDATE t where id= 500000; Read FROM t where id=1;
COMMIT;  (creates T3->T4)
Step 5: T3-> COMMIT;
Step 6: T1-> UPDATE t where id=1; COMMIT;  (creates T4->T1,)

At step 6, when the update statement is executed, T1 is rolled back
because of T3->T4->T1.

But for zheap, step 3 also creates a dependency T1->T3 because of
in-place update. When T4 commits in step 4, it marks T3 as doomed
because of T1 --> T3 --> T4. Hence, in step 5, T3 is rolled back.


--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com