Re: Obscure: correctness of lock manager???

Поиск
Список
Период
Сортировка
От Thomas Schoebel-Theuer
Тема Re: Obscure: correctness of lock manager???
Дата
Msg-id 200308291401.h7TE1sA3027915@eiche.informatik.uni-stuttgart.de
обсуждение исходный текст
Ответ на Re: Obscure: correctness of lock manager???  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Obscure: correctness of lock manager???  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: bug with constraint dependencies? or bug with
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql 7.4b2 bug on column defaults?