Thread: FK locking concurrency improvement

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.

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.  This causes problems with sequencing 
of mixed stderr and stdout and not seeing the last few lines of stdout 
if the process fails or hangs.  The setbuf on stdout shown above 
disables buffering of stdout to match the unbuffered stderr.

That way you don't need to fflush after each printf/fprintf.  I'm not 
sure why fflush of stderr was added because it isn't buffered to begin 
with so is unnecessary.  The problem was with stdout.  YMMV on windows 
but might work.

- Dan

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

Daniel Wood wrote:

> 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.  This
> causes problems with sequencing of mixed stderr and stdout and not
> seeing the last few lines of stdout if the process fails or hangs.
> The setbuf on stdout shown above disables buffering of stdout to
> match the unbuffered stderr.

FWIW it took me a long time but I eventually realized the wisdom in your
suggestion.  I have applied this to the master branch.

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