From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: troubleshooting deadlocks |
Date: | 2004-11-09 20:48:11 |
Message-ID: | 200411091348.11789.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday November 9 2004 10:36, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > I know the original statement is printed right after this, but with
> > complex triggers doing lots of write queries, I'm finding it difficult
> > to identify which subsequent query in the trigger is really the one
> > immediately preceding the deadlock. It would be helpful in debugging
> > if the error message included info on which tables are involved, maybe
> > even the deadlocking query itself, in the "DETAIL" output for future
> > releases.
>
> I suppose the problem here has to do with conflicting SELECT FOR UPDATEs
> from foreign-key references.
That appears to be the issue. We upgraded to 7.4.6 (thanks to slony,
production downtime was minimal), then used 7.4.6 debug output to track
relations, then guessed on fkey references, dropped them, and viola, no
more deadlock.
Thanks,
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-11-09 20:52:39 | Re: server auto-restarts and ipcs |
Previous Message | Devin L. Ganger | 2004-11-09 20:46:19 | Re: Important Info on comp.databases.postgresql.general |