| From: | Tomasz Myrta <jasiek(at)klaster(dot)net> |
|---|---|
| To: | Christoph Haller <ch(at)rodos(dot)fzk(dot)de> |
| Cc: | pgsql-sql(at)postgresql(dot)org, 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-07 10:29:17 |
| Message-ID: | 3E438A7D.1020103@klaster.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Christoph Haller wrote:
<cut>
> 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?
PostgreSQL 7.3 Documentation
3.4. Run-time Configuration
STATEMENT_TIMEOUT (integer)
Aborts any statement that takes over the specified number of milliseconds. A value of zero turns off the timer.
DEADLOCK_TIMEOUT (integer)
This is the amount of time, in milliseconds, to wait on a lock before checking to see if there is a deadlock condition
In this case I suppose 2 things:
- table has a lot of records and you should just wait to finish operation.
- another query locked the table and it is realy a deadlock
Regards,
Tomasz Myrta
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomasz Myrta | 2003-02-07 10:31:46 | Re: SET TIMEOUT equivalent / was: Lock timeout detection |
| Previous Message | Gary Stainburn | 2003-02-07 10:07:28 | efficient count/join query |