Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
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:59:18
Message-ID: 1101355158.44437.133.camel@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2004-11-24 at 22:47 -0500, Bruce Momjian wrote:
> 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.

On a for update?

--

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-11-25 04:01:00 Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Previous Message Bruce Momjian 2004-11-25 03:47:56 Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE