| 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: | Whole Thread | Raw Message | 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 |