Thomas Schoebel-Theuer <[EMAIL PROTECTED]> writes:
> 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???
I haven't looked at dbt3 at all ... what does it do?
We do make a point of
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 b
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
Hi Tom,
the problem persists, even when starting from scratch. I did the following:
# wget
ftp://ftp.de.postgresql.org/mirror/postgresql/source/v7.3.4/postgresql-7.3.4.tar.gz
# tar xzf postgresql-7.3.4.tar.gz
# cd postgresql-7.3.4/
# cat ../mypatch
--- src/backend/storage/lmgr/lock.c~2002-11
Thomas Schoebel-Theuer <[EMAIL PROTECTED]> writes:
> I instrumented the file backend/storage/lmgr/lock.c with printf() statements
> in order to find out the locking behaviour of typical applications using
> locking.
> When I later analyzed the logfiles produced that way, I found a very strange
> b
Hi,
I'm doing research on locking pattern of applications. I chose PostgreSQL
7.3.3 as an example application due to availability of sourcecode.
I instrumented the file backend/storage/lmgr/lock.c with printf() statements
in order to find out the locking behaviour of typical applications using
lo
