| From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
|---|---|
| To: | Satoshi Nagayasu <nagayasus(at)nttdata(dot)co(dot)jp> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: lock timeout patch |
| Date: | 2004-06-28 19:24:54 |
| Message-ID: | 1088450694.31168.71.camel@camel |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2004-06-28 at 02:16, Satoshi Nagayasu wrote:
> Tom Lane wrote:
> > I'd accept a mechanism to enforce a timeout at the lock level if you
> > could show me a convincing use-case for lock timeouts instead of
> > statement timeouts, but I don't believe there is one. I think this
> > proposal is a solution in search of a problem.
>
> I think statement_timeout and lock_timeout are different.
>
> If I set statement_timeout to 1000 to detect a lock timeout,
> I can't run a query which takes over 1 sec.
>
> If a lock wait is occured, I want to detect it immediately,
> but I still want to run a long-running query.
>
How is your problem not solved by NOWAIT?
http://developer.postgresql.org/docs/postgres/sql-lock.html
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-06-28 19:39:02 | Re: improper call to spi_printtup ??? |
| Previous Message | Mike Rylander | 2004-06-28 18:40:10 | Quick question regarding tablespaces |