From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, kaigai(at)kaigai(dot)gr(dot)jp, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review: Extra Daemons / bgworker |
Date: | 2012-11-30 10:09:29 |
Message-ID: | m24nk7csh2.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Markus Wanner <markus(at)bluegap(dot)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:
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-11-30 10:15:47 | Re: Review: Extra Daemons / bgworker |
Previous Message | Vik Reykja | 2012-11-30 10:05:04 | Re: DEALLOCATE IF EXISTS |