Re: Obscure: correctness of lock manager??? - Mailing list pgsql-hackers

From Thomas Schoebel-Theuer
Subject Re: Obscure: correctness of lock manager???
Date
Msg-id 200308291401.h7TE1sA3027915@eiche.informatik.uni-stuttgart.de
Whole thread Raw
In response to Re: Obscure: correctness of lock manager???  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Obscure: correctness of lock manager???
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: bug with constraint dependencies? or bug with
Next
From: Tom Lane
Date:
Subject: Re: pgsql 7.4b2 bug on column defaults?