Tom Lane <tgl@sss.pgh.pa.us> writes:
> Well, yeah, but you *must* trust those commands because every last bit
> of your database content passes through their hands. That is not an
> argument why you need to trust a scheduling facility --- much less the
> tasks it schedules.
It seems to me that CREATE FUNCTION maintenance.foo() ... SECURITY
DEFINER means that I can schedule tasks that will not run a
superuser. On the reliability, see above.
> I still say that every use case so far presented here would be equally
> if not better served outside the database. Putting it inside just
> creates more failure scenarios and security risks.
I can understand why you say that, but I'll have to disagree.
The fact that the database server is still available when pgbouncer
crashes, for example, still means that none of my applications are
able to connect.
When the current PGQ (or slony) code crashes, it's already C loaded code
that crashes, and it already takes PostgreSQL down with it.
I'm not the security oriented paranoid^W guy, so I won't ever try to
argue about that world, and not with you.
All in all, when the daemons I'm considering running as user processes
do crash, the fact that PostgreSQL is still alive means nothing for
me. Have its supervisor trigger a fast shutdown and restart sounds way
more reliable from here, the alternative being some alerting system
wakes me up and I get to restart the failed services while my
application is not available, but PostgreSQL is (but for no one).
Regards,
--
dim
