Обсуждение: 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