Re: select from update from select?

From: Dave Gomboc <dave(at)cs(dot)ualberta(dot)ca>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Tambet Matiisen <tambet(dot)matiisen(at)mail(dot)ee>, <pgsql-sql(at)postgresql(dot)org>
Subject: Re: select from update from select?
Date: 2003-02-20 01:46:11
Message-ID: Pine.LNX.4.44.0302191841480.10556-100000@boyne.cs.ualberta.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

> This has come up before - check the archives for details.
>
> One solution is to have a "processed" flag with values:
>
> U - unprocessed
> X - executing
> D - done
>
> You claim a job by changing from U to X - this takes very little time, so your
> worker processes can simply sit in a loop trying. When work is complete the
> flag is marked D.
> This has the added advantage that you can spot rows where processing started
> but didn't complete due to a crash etc.
>
> Another solution if you know how many workers you have is to have a manager
> process which tags each job with a worker ID, but this does tend to make the
> manager a point of failure.

In my system, when reservation_time is not null, the state is not U, and
when the result field (not described in my email) is not null, the state
is neither U nor X. I do use reservation_time (and 'now()') to reclaim
tasks that have not completed after a certain (dynamic) length of time
(e.g. due to crash). So I think I'm attempting to implement essentially
what you describe. ;-)

I guess what you're saying is that in the big picture, the period of
contention for jobs between, say, 60 concurrent clients will really be
quite small, so don't worry about eliminating it?

Dave

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message mallah 2003-02-20 04:02:25 Re: simple join problem
Previous Message Michael Nachbaur 2003-02-19 22:55:36 Date-range LEFT OUTER JOIN not using an index