Re: Review: Extra Daemons / bgworker - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Review: Extra Daemons / bgworker
Date
Msg-id m24nk7csh2.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Review: Extra Daemons / bgworker  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Review: Extra Daemons / bgworker  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Review: Extra Daemons / bgworker  (Markus Wanner <markus@bluegap.ch>)
List pgsql-hackers
Markus Wanner <markus@bluegap.ch> writes:
>> However, as you say, maybe we need more coding examples.
>
> Maybe a minimally usable extra daemon example? Showing how to avoid
> common pitfalls? Use cases, anybody? :-)

What about the PGQ ticker, pgqd?
 https://github.com/markokr/skytools/tree/master/sql/ticker
https://github.com/markokr/skytools/blob/master/sql/ticker/pgqd.c

Or maybe pgAgent, which seems to live there, but is in C++ so might need
a rewrite to the specs:

http://git.postgresql.org/gitweb/?p=pgadmin3.git;a=tree;f=pgadmin/agent;h=ebbcf71bd918efdc82466785ffac6f2ac3443847;hb=HEAD

Maybe it would be easier to have a version of GNU mcron as an extension,
with the abitity to fire PostgreSQL stored procedures directly?  (That
way the cron specific parts of the logic are already implemented)
 http://www.gnu.org/software/mcron/

Another idea would be to have a pgbouncer extension. We would still need
of course to have pgbouncer as a separate component so that client
connection can outlive a postmaster crash, but that would still be very
useful as a first step into admission control. Let's not talk about the
feedback loop and per-cluster resource usage monitoring yet, but I guess
that you can see the drift.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



pgsql-hackers by date:

Previous
From: Vik Reykja
Date:
Subject: Re: DEALLOCATE IF EXISTS
Next
From: Pavel Stehule
Date:
Subject: Re: Review: Extra Daemons / bgworker