Markus Wanner <mar...@bluegap.ch> writes: > To simplify, you might want to start a bgworker on database 'postgres', > which then acts as a sub-coordinator (and doesn't really need to use its > database connection).
Yeah, that sounds like the simplest way forward, so that it's easy for this "user daemon" to communicate with the coordinator. Typically this would start a backend and LOAD a module, which would enter the user daemon main loop, I guess. Then all the usual backend code facilities are there, even SQL and calling user defined function. > Well, there are different types of imessages defined in imsg.h. If you are > coding something within Postgres, you'd just add all the required messages > types there. There's no such thing as an external registration for new > message types. Given that imessages can have a payload, maybe the simplest way there would be to add a "IMSGT_EXEC_QUERY_PARAMS" message type, the payload of which would be composed of the SQL text and its parameters. I get it that requiring a bgworker backend connected to a given database is already part of the API right? > So, the bgworker infrastructure could probably satisfy the internal > communication needs. But how does this ticker daemon talk to the outside? > Does it need to open a socket and listen there? Or do the requests to that > queue come in via SQL? The ticker only job is to manage a "ticks" table per database. All it needs for that is a libpq connection, really, but given your model it'd be a single backend (worker) that would send imessages to the coordinator so that a background worker would tick, by executing this SQL: select pgq.ticker()). So that would be a lot of changes to follow your facilities, it's unclear to me how much we're twisting it so that it fits. Well, maybe that's not a good example after all. Dave, want to see about pgagent? Regards, -- Dimitri Fontaine PostgreSQL DBA, Architecte -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
