Re: queueing via database table?

From: Richard Huxton <dev(at)archonet(dot)com>
To: Steve Atkins <steve(at)blighty(dot)com>
Cc: pgsql general <pgsql-general(at)postgresql(dot)org>
Subject: Re: queueing via database table?
Date: 2007-01-03 08:37:30
Message-ID: 459B6B4A.5030903@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Steve Atkins wrote:
>
> Holding a lock while generating the thumbnail doesn't
> sound like a great idea, and I think that the select
> for update will end up serialising the requests.
>
> I'd add a "rendering" field, text, defaulting
> to an empty string.
>
> Then do a "select for update where ... and rendering = '' limit 1",
> update the rendering field to the hostname of the box doing the
> work and commit. Render the thumbnail. Delete the record.

Assuming each processing host keeps its connection open, I'd store the
process-id instead (get via function pg_backend_pid()). Also have a
separate status (pending|processing|done) and timestamps to track when
each status is set. Only delete rows that have been marked "done" for a
certain length of time.

This will let you spot when a host has stopped processing (e.g. crashed)
and also let you measure throughput on particular hosts.

The other thing to be aware of is that queries of the SELECT FOR UPDATE
LIMIT 1 form can return 0 rows. Open two psql connections and try it to
see what happens. You'll need to have the processing clients retry the
query in this case.

HTH
--
Richard Huxton
Archonet Ltd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dawid Kuroczko 2007-01-03 09:14:54 Re: queueing via database table?
Previous Message Markus Schiltknecht 2007-01-03 08:32:13 Re: Geographical redundancy