On 4/8/22 08:58, Magnus Hagander wrote:
> A side-note on this, which of course won't help the OP at this point,
> but if the general best practice of not running the application with a
> highly privileged account is followed, the problem won't occur (it will
> just fail early before breaking things). DISABLE TRIGGER ALL requires
> either ownership of the table or superuser permissions, none of which
> it's recommended that the application run with. Doesn't help once the
> problem has occurred of course, but can help avoid it happening in the
> future.
It gets even better further down in that code, where it UPDATEs
pg_constraint directly. That not only requires superuser but also catupd
permissions (which are separate from superuser for a reason).
Indeed.The fact that's in the code is sadly an indicator of how many people run their app as superuser :(
Interesting conversation. Yes, the developer generally has superuser DB because they need to create the DB, etc. And, during testing, I’m sure their test user has super user privileges as well. I bet they don’t set up the DB with one user and then test with a non-SU user during test and the corollary is I bet the DB user used in production is also a super user in the majority of the installations. I’ve never seen this discussed. I’m not hugely active in the Rails community. They never liked me (or perhaps that was projection on my part).
