Re: In-place updates and serializable transactions

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: joshua(dot)yanovski(at)gmail(dot)com
Cc: kuntalghosh(dot)2007(at)gmail(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, hlinnaka(at)iki(dot)fi, Jeff Davis <pgsql(at)j-davis(dot)com>, joe(dot)conway(at)crunchydata(dot)com
Subject: Re: In-place updates and serializable transactions
Date: 2018-11-14 21:39:45
Message-ID: CACjxUsOPzRZsomSUU9rfba_Cy3yqT1txwaE9oV4_ztxCavysSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 14, 2018 at 5:43 AM Joshua Yanovski
<joshua(dot)yanovski(at)gmail(dot)com> wrote:

> This is only a personal anecdote, but from my own experience with serializability, this sort of blind update isn't often contended in realistic workloads.

> So, if this only affects transactions with blind updates, I doubt it will cause much pain in real workloads (even though it might look bad in benchmarks which include a mix of blind writes and rmw operations). Particularly if it only happens if 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.

--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-11-14 21:41:27 Re: Doc patch on psql output formats
Previous Message Robert Haas 2018-11-14 21:36:49 Re: Refactoring the checkpointer's fsync request queue