Re: Obscure: correctness of lock manager???

Thomas Schoebel-Theuer <schoebel@informatik.uni-stuttgart.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