Re: bg worker: overview

Markus Wanner <markus(at)bluegap(dot)ch> writes:
> For one, yes, I want to avoid having to start ones too often. I did look
> into letting these background workers switch the database connection, but
> that turned out not to be worth the effort.
>
> Would you prefer a background worker that's not connected to a database, or
> why are you asking?

Trying to figure out how it would fit the PGQ and pgagent needs. But
maybe user defined daemons should be sub-coordinators (I used to think
about them as "supervisors") able to talk to the coordinator to get a
backend connected to some given database and distribute work to it.

You're using iMessage as the data exchange, how are you doing the work
distribution? What do you use to tell the backend what is the processing
you're interrested into?

> Go ahead, re-use the background workers. That's what I've published
> them for

Hehe :) The aim of this thread would be to have your input as far as
designing an API would go, now that we're about on track as to what the
aim is.

> To be honest, I still don't quite grok the concept behind PGQ. So I cannot
> really comment on this.

In very short, the idea is a clock that ticks and associate
current_txid() to now(), so that you're able to say "give me 3s worth of
transactions activity from this queue". It then provides facilities to
organise a queue into batches at consumer request, and for more details,
see there:

http://github.com/markokr/skytools-dev/blob/master/sql/ticker/pgqd.c
http://github.com/markokr/skytools-dev/blob/master/sql/ticker/ticker.c

But the important thing as far as making it a child of the coordinator
goes would be, I guess, that it's some C code running as a deamon and
running SQL queries from time to time. The SQL queries are calling C
user defined functions, provided by the PGQ backend module.

Regards,
--
dim