From: Vilinski Vladimir <vilinski@web.de>
To: pgsql-sql@postgresql.org
Subject: WHY transaction waits for another transaction?
Date: Tue, 14 Jun 2005 13:12:13 +0200
Message-ID: <141218891@web.de> (raw)
Hallo
I'm porting one Oracle Application to Postgres. This Programm uses "long
living" Transactions.
During the execution of transaction Nr:10295 (PID:18430) one new transaction with
Nr:10339 (PID:18431) starts, that writes one record into the table. But this new
transaction never stops, because it tries to set one ShareLock to its
parrent transaction Nr:10295.
My problem is, how can i found out - WHY the second transaction waits
for end of first transaction?
Is there a tool for analyzing such deadlocks?
pg_lock output
relation database transacti pid mode granted
251553 251331 18430 AccessShareLock t
251553 251331 18430 RowExclusiveLock t
251487 251331 18430 AccessShareLock t
251487 251331 18430 RowShareLock t
251487 251331 18430 RowExclusiveLock t
251492 251331 18430 AccessShareLock t
251494 251331 18431 AccessShareLock t
251434 251331 18434 AccessShareLock t
251407 251331 18431 AccessShareLock t
251434 251331 18430 AccessShareLock t
251429 251331 18430 AccessShareLock t
251548 251331 18430 AccessShareLock t
251548 251331 18430 RowExclusiveLock t
251575 251331 18430 AccessShareLock t
251458 251331 18430 AccessShareLock t
251524 251331 18434 AccessShareLock t
10293 18434 ExclusiveLock t
251482 251331 18430 AccessShareLock t
251482 251331 18430 RowShareLock t
251492 251331 18431 AccessShareLock t
251577 251331 18431 AccessShareLock t
251477 251331 18431 AccessShareLock t
251567 251331 18431 AccessShareLock t
251417 251331 18431 AccessShareLock t
251492 251331 18434 AccessShareLock t
1247 251331 18431 AccessShareLock t
16839 251331 18438 AccessShareLock t
251494 251331 18430 AccessShareLock t
251494 251331 18430 RowShareLock t
251494 251331 18430 RowExclusiveLock t
251434 251331 18431 AccessShareLock t
251553 251331 18431 AccessShareLock t
251494 251331 18434 AccessShareLock t
251392 251331 18431 AccessShareLock t
251472 251331 18430 AccessShareLock t
251472 251331 18430 RowShareLock t
251526 251331 18431 AccessShareLock t
251577 251331 18430 AccessShareLock t
251482 251331 18431 AccessShareLock t
251482 251331 18431 RowShareLock t
251472 251331 18431 AccessShareLock t
251472 251331 18431 RowShareLock t
251472 251331 18431 RowExclusiveLock t
251487 251331 18434 AccessShareLock t
251553 251331 18434 AccessShareLock t
251407 251331 18430 AccessShareLock t
251407 251331 18430 RowShareLock t
10381 18438 ExclusiveLock t
251487 251331 18431 AccessShareLock t
251487 251331 18431 RowShareLock t
251487 251331 18431 RowExclusiveLock t
251509 251331 18430 AccessShareLock t
251386 251331 18431 AccessShareLock t
251394 251331 18430 AccessShareLock t
10339 18431 ExclusiveLock t
251407 251331 18434 AccessShareLock t
10295 18430 ExclusiveLock t
251422 251331 18430 AccessShareLock t
10295 18431 ShareLock f
_________________________________________________________________________
Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle
Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: vilinski@web.de
Subject: Re: WHY transaction waits for another transaction?
In-Reply-To: <141218891@web.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox