On Mon, Jan 16, 2017 at 9:40 AM, Thomas Munro <thomas.mu...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers