From: | Christoph Haller <ch(at)rodos(dot)fzk(dot)de> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Cc: | shariq77(at)yahoo(dot)com, lud_nowhere_man(at)yahoo(dot)com |
Subject: | Re: Lock timeout detection in postgres 7.3.1 |
Date: | 2003-02-06 12:12:29 |
Message-ID: | 3E42512D.D6014A75@rodos.fzk.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> >
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Julian Scarfe | 2003-02-06 12:17:31 | Re: TIME vs. TIMESTAMP data type |
Previous Message | Ludwig Lim | 2003-02-06 12:08:51 | Re: TIME vs. TIMESTAMP data type |