> On Sep 12, 2022, at 15:51, Bryn Llewellyn <b...@yugabyte.com> 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.
