Tom,
I just realized that I probably could have misinterpreted the locktag
information. This could have caused the conflicts in my postprocessing.
Apologies if that was the reason. I'm running further checks to
resolve that problem.
However, what remains strange is that the lockmanager is never blocking,
at least when running DBT3. The short patch shows with high confidence
that there is no blocking at all.
I'm pretty sure that I got the output of the backend processes, because
I included getpid() in the full version of the instrumentation. The
stripped-down version showed up the "lock\n" lines, so I am sure that
I got the backend output. I'll incude getpid() even there to be really
sure.
If the lock manager were correct in that never any blocking orrurs
in DBT3, then I would have another problem: the experiment would
be probably meaningless for my research. In that case, do you know
any benchmark / application which leads to heavy conflicts in the
lock manager such that blocking occurs?
Do you have any clue whether it really could happen that really
NEVER any blocking occurs when running the DBT3 benachmark with 8
or 16 parallel backend processes???
Thanks for your patience,
Thomas
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
