Re: Obscure: correctness of lock manager???

Thomas Schoebel-Theuer <schoebel(at)informatik(dot)uni-stuttgart(dot)de> writes:
> the problem persists, even when starting from scratch. I did the following:

> + printf("lock\n"); fflush(stdout);
> +

> $ grep lock run/dbt3_logfile | wc -l

I'd bet that your logfile is not accumulating postmaster stdout, but
only stderr. Or maybe not even stderr --- where are you getting it
from exactly? Perhaps you're logging client-side output, rather than
that of the backends.

> Tom, it sounds really strange, and I also cannot nearly believe it,
> but I could imagine why that problem (if it really exists) was
> not detected before.

If I actually believed your experiment, it would prove that LockAcquire
wasn't being called at all. It is trivial to demonstrate that this is
not so, eg, attach to a backend with gdb and set a breakpoint at
LockAcquire. Or, if you'd like some more macroscopic proof that the
lock manager is doing something, try this:

psql session 1:

create table a(f1 int);
create table b(f1 int);
begin;
lock table a;

psql session 2:

begin;
lock table b;
lock table a;
-- note that it blocks waiting for session 1's lock

back in session 1:

lock table b;
-- note deadlock failure report

regards, tom lane