Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
With that change, I didn't see run_workload report any errors, but maybe
I don't know where to look.
The error is captured in dbt2/scripts/output/*/client/error.log, where *
is the run directory.
Hm ... here's what I see in there:
Thu Sep 14 15:19:16 2006
tid:-1430387232 client.c:129
20 DB worker threads have started
Thu Sep 14 15:19:31 2006
tid:1087957312 libpq/dbc_new_order.c:111
ERROR: deadlock detected
DETAIL: Process 5334 waits for ShareLock on transaction 3505055; blocked by
process 5363.
Process 5363 waits for ShareLock on transaction 3505049; blocked by process
5334.
CONTEXT: SQL statement "UPDATE stock
SET s_quantity = s_quantity - 10
WHERE s_i_id = 48368
AND s_w_id = 1"
[snip]
Is the deadlock failure expected?
Ooh, that's interesting. Deadlock failure is possible although I think
we would all prefer that it didn't happen. In the scheme of the
workload having failed transactions is ok. So with respect to having an
invalid test run it's something I wouldn't worry about too much if it's
infrequent.
Mark
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
