| From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
|---|---|
| To: | Jeff Amiel <jamiel(at)istreamimaging(dot)com> |
| Cc: | Mark Harrison <mh(at)pixar(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: using database for queuing operations? |
| Date: | 2004-09-20 20:39:57 |
| Message-ID: | 20040920203957.GG1297@decibel.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Sep 20, 2004 at 03:08:29PM -0500, Jeff Amiel wrote:
> Add a column to the nameq table designating the 'state' of the image.
> Then your logic changes to "select * from nameq where serial = (select
> min(serial) from nameq) and state="UNPROCESSED" (or whatever)
> So you select for update, change the state, then process the
> image....then delete.
> Viola!
You should also consider what happens if the conversion program can't
update the state to processed for some reason. For example, pgsql might
get shutdown unexpectedly, or the conversion process could.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2004-09-20 20:41:51 | unique constraints on foreign keys |
| Previous Message | Mark Harrison | 2004-09-20 20:23:49 | Re: using database for queuing operations? |