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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers