> > > > T1 (within psql): > > BEGIN; DELETE FROM <some_table> ; > > DELETE n > > > > T2 (within psql): > > BEGIN; DELETE FROM <some_table> ; > > <waiting forever> > > ... > > I don't think there is a deadlock in the example > given above. If I'm not mistaken a deadlock occurs if > both transactions are waiting for each other to > release the lock (i.e T1 waits for T2 to release > locks/resources while T2 is also waiting for T1 to > release locks/resources. In the above example, T1 > doesn't wait for T2 to do something before finishes > the transaction (Only T2 is waiting for T1 to finish), > hence the condition for deadlock is not met. > Yupp, I agree. But from former DBMS I was dealing with, I know this SET TIMEOUT called feature, which if properly set terminated processes like that hanging on T2. Is there something comparable within Postgres?
Regards, Christoph ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
