Re: FK locking concurrency improvement

Daniel Wood wrote:
> As part of 0ac5ad5134f2769ccbaefec73844f8504c4d6182
> the permutations in test/isolation/fk-deadlock2.spec and elsewhere
> were removed. Is it the intent that these tests no longer do
> anything useful? I was expecting a failure in the test with some
> work I'm doing and was confused, after a merge from the upstream
> 9.3, that the test didn't fail until I noticed the test is no longer
> running the permutations.

No, you're misunderstanding. When the spec file specifies permutations,
then those are exactly the permutations that are run. When the spec
does not list any permutations, then the test driver runs all the
possible permutations.

This was made possibly by a change to isolationtester that an
"impossible" permutation did not cause the test to die, but instead to
continue by reporting that the permutation is impossible. That way, we
ensure that not only the listed permutations are running and passing,
but also that the set of permutations that are possible does not change.
(An "impossible" permutation is one that requires running a command in a
session that is in blocked state, something which is clearly
impossible.)

In hindsight, we could have committed this change separately.

> FYI, I saw some comments and adding fflush's into isolationtester.c.
> I ran into the same problem with debugging tests when they
> failed/hung in the middle. A simple "setbuf(stdout, NULL)" at the
> beginning of main gets rid of the problem where line buffering
> becomes block buffering when redirecting stdout to a file.

Interesting. I'm not sure it's worth messing with this now (given that
the current coding works everywhere), but if there's a strong reason to
do it that way we can certainly change it.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services