On Tue, 13 Feb 2007, Marc Munro wrote:
On Mon, 2007-12-02 at 00:10 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
Consider a table C containing 2 child records C1 and C2, of parent P.
If transaction T1 updates C1 and C2, the locking order of the the
records will be C1, P,
On Mon, 2007-12-02 at 00:10 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
Consider a table C containing 2 child records C1 and C2, of parent P.
If transaction T1 updates C1 and C2, the locking order of the the
records will be C1, P, C2. Another transaction, T2, that attempts
Marc Munro [EMAIL PROTECTED] writes:
From an application developer's standpoint there are few options, none
of them ideal:
How about
4) Make all the FK constraints deferred, so that they are only checked
at end of transaction. Then the locking order of transactions that only
modify C is
On Tue, 2007-13-02 at 11:38 -0500, Tom Lane wrote:
Marc Munro [EMAIL PROTECTED] writes:
From an application developer's standpoint there are few options, none
of them ideal:
How about
4) Make all the FK constraints deferred, so that they are only checked
at end of transaction. Then
On Thu, Feb 08, 2007 at 08:47:42AM -0800, Marc Munro wrote:
One of the causes of deadlocks in Postgres is that its referential
integrity triggers can take locks in inconsistent orders. Generally a
child record will be locked before its parent, but not in all cases.
Where would PostgreSQL lock
On Sun, 2007-11-02 at 12:21 -0600, Jim C. Nasby wrote:
On Thu, Feb 08, 2007 at 08:47:42AM -0800, Marc Munro wrote:
One of the causes of deadlocks in Postgres is that its referential
integrity triggers can take locks in inconsistent orders. Generally a
child record will be locked before its
Marc Munro [EMAIL PROTECTED] writes:
Consider a table C containing 2 child records C1 and C2, of parent P.
If transaction T1 updates C1 and C2, the locking order of the the
records will be C1, P, C2. Another transaction, T2, that attempts to
update only C2, will lock the records in order C2,
I am going to restate my earlier proposal, to clarify it and in the hope
of stimulating more discussion.
One of the causes of deadlocks in Postgres is that its referential
integrity triggers can take locks in inconsistent orders. Generally a
child record will be locked before its parent, but not
On Thu, 2007-02-08 at 17:47, Marc Munro wrote:
[snip] One of the causes of deadlocks in Postgres is that its referential
integrity triggers can take locks in inconsistent orders. Generally a
child record will be locked before its parent, but not in all cases.
[snip]
The problem is that
On Thu, 2007-08-02 at 18:06 +0100, Csaba Nagy wrote:
The problem is that eliminating the deadlock is still not the complete
cake... the interlocking still remains, possibly leading to degraded
performance on high contention on very common parent rows. The real
solution would be when an update
10 matches
Mail list logo
