What are your ideas of applying a change similar to above to actually being a superuser ?
That is adding a check for "superuser being currently available" to function superuser() in ./src/backend/utils/misc/superuser.c ? It could be as simple as a flag that can be set only at startup for maximum speed - though the places needing superuser check are never in speed-critical path as far as I have seen. Or it could be more complex and dynamix, like having a file similar to pg_hba.conf that defines the ability to run code as superuser based on a set of attributes each of which could be * meaning "any" These could be * database (to limit superuser to only certain databases) * session user (to allow only some users to become superuser, including via SECURITY DEFINER functions) * backend pid (this would allow kind of 2-factor authentication - connect, then use that session's pid to add a row to pg_ok_to_be_sup.conf file, then continue with your superuser-y stuff) * valid-until - this lets one allow superuser for a limited period without fear of forgetting top disable it This approach would have the the benefit of being very low-code while delivering the extra protection of needing pre-existing access to filesystem to enable/disable . For easiest usability the pg_ok_to_be_sup.conf file should be outside pg_reload_conf() - either just read each time the superuser() check is run, or watched via inotify and reloaded each time it changes. Cheers, Hannu P.S: - thanks Magnus for the "please don't top-post" notice - I also need to remember to check if all the quoted mail history is left in when I just write a replay without touching any of it. I hope it does the right thing and leaves it out, but it just might unders some conditions bluntly append it anyway just in case :)