Bill Moseley wrote:
> I seemed to have resolved this issue by a:
>
> LOCK TABLE account IN EXCLUSIVE MODE;
>
> at the very start of the transaction to prevent that transaction
> from running in parallel.
>
> The transaction has quite a few selects and inserts and a few updates.
> I was hopin
I seemed to have resolved this issue by a:
LOCK TABLE account IN EXCLUSIVE MODE;
at the very start of the transaction to prevent that transaction
from running in parallel.
The transaction has quite a few selects and inserts and a few updates.
I was hoping to not lock at the start of the tran
In response to Bill Moran :
> In response to Bill Moseley :
>
> > On Sun, May 03, 2009 at 09:08:29PM -0400, Tom Lane wrote:
> > > > There are no other updates to that account table in the transaction, so
> > > > I'm
> > > > confused how that is causing a deadlock.
> > >
> > > Is there more than
In response to Bill Moseley :
> On Sun, May 03, 2009 at 09:08:29PM -0400, Tom Lane wrote:
> > > There are no other updates to that account table in the transaction, so
> > > I'm
> > > confused how that is causing a deadlock.
> >
> > Is there more than one row with the target id?
>
> No. It's a
On Sun, May 03, 2009 at 09:08:29PM -0400, Tom Lane wrote:
> > There are no other updates to that account table in the transaction, so I'm
> > confused how that is causing a deadlock.
>
> Is there more than one row with the target id?
No. It's a single SERIAL primary key.
> Does the account tab
Bill Moseley writes:
> Then when I run the test script (which runs the same transaction in two
> processes at the same time) and get a deadlock the same query is shown twice
> both with "waiting" set true:
> UPDATE account set foo = 123 where id = $1
> And if I remove that update from th
On Sat, May 02, 2009 at 11:48:21AM -0400, Tom Lane wrote:
> Bill Moseley writes:
> > Not getting any nibbles, so allow me to try a short question:
> > If I have a deadlock situation (that will be reported as such by
> > Postgresql once the deadlock_timeout passes), does pg_stat_activity
> > show t
Bill Moseley writes:
> Not getting any nibbles, so allow me to try a short question:
> If I have a deadlock situation (that will be reported as such by
> Postgresql once the deadlock_timeout passes), does pg_stat_activity
> show the queries that are blocking each other?
In 8.2 or later it should
Not getting any nibbles, so allow me to try a short question:
If I have a deadlock situation (that will be reported as such by
Postgresql once the deadlock_timeout passes), does pg_stat_activity
show the queries that are blocking each other?
I'm wondering if I'm misinterpreting what I'm seeing be
I need a bit of help understanding what might be causing a deadlock.
To duplicate the problem I'm running a test script that forks two
child processes. Each child runs the same transaction and thus the
order of execution is exactly the same. (i.e. not like the typical
deadlock where the order o
10 matches
Mail list logo
