Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
