Bill Moran wrote:
> On Wed, 19 Aug 2015 19:45:47 +0200
> jacques klein <jacques.klei@googlemail.com> wrote:
>
> > Well, sorry David, I don't understand what you mean,
> >
> > let me explain what I want to do: in short, IPC between "background
> > workers".
> >
> > I am trying to transform my app. from a multi-threaded C SQL-client into
> > some "background workers", execution speed beeing the goal (avoid
> > network io).
> > Worker start/stopping is nicely solved by server start/stop, but I have
> > also to do some messaging/notifying between my worker processes, and
> > would like to use a Postgres based solution instead of the usual unix or
> > network ipc, or course by avoiding polling (tables acting as message
> > queues).
>
> I think what David is saying, and what I would suggest, is the
> following:
>
> * It's not possible to have a trigger execute in the background
> * Create a background job that runs perpetually and listens for
> notification that it has work to do (i.e. it sleeps until notified)
> * Notify the job from the trigger
You could use shm_mq for IPC between backend (trigger) and bgworker, but
what should the backend do when the bgworker is not running for whatever
reason? One option is to curl up and die of course (i.e. abort the
transaction that fires the action). Also consider what happens if your
backend sends the notify and commits, and before the bgworker does its
stuff the system crashes. You will be happy to have things queued in a
database table ...
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services