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
