Re: An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> I also have longer term plans to show the first and third of them
> running with the read-only transaction moved to a standby server.
> Kevin Grittner gave me the idea of multi-server isolation tests when I
> mentioned my WIP SERIALIZABLE DEFERRABLE-on-standbys patch off-list,

Being able to do that with the isolation tester has been mentioned a
coupled of times, particularly from 2ndQ folks who worked in BDR. I
think that it has been actually patched in this sense, so perhaps you
could reuse the work that has been done there.

> which prompted me to realise that our existing SSI tests aren't very
> interesting for that because they all rely on the behaviour of
> SERIALIZABLE, not SERIALIZABLE DEFERRABLE. So I figured we'd better
> have some tests that show show that working on a single node system
> first.

Makes sense.

> Upon reflection, either 2 or 3 might be considered more beautiful than
> 4, depending on how others feel about extending the remit of the
> existing pg_blocking_pid function. I'd be happy to post a new patch
> using one of those approaches if others feel it'd be better that way.

Well, either 1, 2 or 3 basically duplicate what the wait events
tracked via latch.c for SafeSnapshot are doing when a client scans
pg_stat_activity, so at the end even if that's not the most beautiful
thing I have seen, this does not seem worth making the backend more
complicated for a facility that we already have. What I am wondering
though is if it would be interesting to make the list of potential
wait events backends are waiting for at some transaction point
configurable in the isolation tester. For example say having as step a
way to switch between wait events to wait for and be able to make that
usable as part of a permutation. I am not sure if there are actual use
cases for such a fancy facility, so if things prove to become more
complicated in the future we could consider it. But honestly I am now
of the opinion that this time has not come yet.
--
Michael