From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <pg(at)rbt(dot)ca> |
Cc: | ronzo <m(dot)ronzoni(at)nocerainformatica(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE |
Date: | 2004-11-25 03:47:56 |
Message-ID: | 200411250347.iAP3lvW05219@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rod Taylor wrote:
> On Wed, 2004-11-24 at 22:13 -0500, Bruce Momjian wrote:
> >
> > We have discussed this at length and no one could state why having an
> > timeout per lock is any better than using a statement_timeout.
>
> Actually, I hit one.
>
> I have a simple queue and a number of processes pulling jobs out of the
> queue. Due to transactional requirements, the database is appropriate
> for a first cut.
>
> Anyway, a statement_timeout of 100ms is usually plenty to determine that
> the job is being processed, and for one of the pollers to move on, but
> every once in a while a large job (4 to 5MB chunk of data) would find
> itself in the queue which takes more than 100ms to pull out.
>
> Not a big deal, just bump the timeout in this case.
>
> Anyway, it shows a situation where it would be nice to differentiate
> between statement_timeout and lock_timeout OR it demonstrates that I
> should be using userlocks...
Wouldn't a LOCK NOWAIT be a better solution? That is new in 8.0.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2004-11-25 03:59:18 | Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE |
Previous Message | Tom Lane | 2004-11-25 03:36:35 | Re: Stack not being popped correctly (was: Re: [HACKERS] plpgsql lacks generic identifier for record in triggers...) |