> On Sep 12, 2022, at 15:51, Bryn Llewellyn <bryn@xxxxxxxxxxxx> wrote: > The implication is that every client program must follow every database call with defensive code to detect error "57P01" and programmatically re-try. That situation exists even without the ability for a role to kill other sessions authorized to the same role. A superuser (or role granted pg_signal_backend) could have terminated it, the connection could have broken due to a network failure (which caused the backend to roll back and terminate), or the server could have crashed. Pragmatically, the only real additional risk cases here are: (a) An intrusion using that role, (b) A client program that for some reason can issue a legitimate pg_terminate_backend() call, but that has a bug that causes it to use it inappropriately. In the case of (a), pg_terminate_backend() is the least of your worries, and I have a hard time seeing (b) as a real-world risk that requires a new PostgreSQL feature to defending again. Also pragmatically, it would be a *very* significant behavior shift if roles could not by default signal other sessions authorized to the same role, so it would be unwise to introduce that feature and have it be revoked from non-superusers by default. And, if it's not revoked by default, it's not going be very widely used except for ultra-locked-down environments. I don't think it would hurt anything to introduce it, but I'm not sure the utility is there.
