Re: bg worker: overview

Markus Wanner <markus(at)bluegap(dot)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