Skip site navigation (1) Skip section navigation (2)

Re: Obscure: correctness of lock manager???

From: Thomas Schoebel-Theuer <schoebel(at)informatik(dot)uni-stuttgart(dot)de>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Obscure: correctness of lock manager???
Date: 2003-08-29 14:01:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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

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,


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2003-08-29 14:03:58
Subject: Re: pgsql 7.4b2 bug on column defaults?
Previous:From: Greg StarkDate: 2003-08-29 13:56:45
Subject: Re: bug with constraint dependencies? or bug with

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group