SET TIMEOUT equivalent / was: Lock timeout detection

From: Christoph Haller <ch(at)rodos(dot)fzk(dot)de>
To: pgsql-sql(at)postgresql(dot)org
Subject: SET TIMEOUT equivalent / was: Lock timeout detection
Date: 2003-02-07 09:35:43
Message-ID: 3E437DEF.406C7445@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?
>
Sorry to bother again with my question. Is it too stupid or
trivial to this list? Should I send it to NOVICE?
Regards, Christoph

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message dev 2003-02-07 09:36:54 Re: which will be faster? w/ or w/o indices
Previous Message waimeng 2003-02-07 08:29:38 PostgreSQL 7.3.1 multiple schema select query error: java.sql.SQLException: ERROR: parser: parse error at or near "."