Thomas Schoebel-Theuer <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
