Markus Wanner <mar...@bluegap.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
