Bryn Llewellyn <bryn@xxxxxxxxxxxx> writes: > I can't agree with you about risks and probability, though. The general literature of security threats often makes the point that disgruntled employees (current or very recently former) who know the code in question do sometimes wreak havoc—sometimes just for sport. The general risk that the unrestricted ability to use "pg_terminate_backend()" to kill sessions started by one's peers is ordinary denial of service—notwithstanding the possibility for automatic re-connect. It still steals time and resources. I'm not sure that this argument has much to recommend it. If you are able to issue arbitrary SQL commands, you can cause effective denials-of-service in many ways. A couple of random examples: * launch a query that will eat indefinite amounts of CPU and/or disk. * "LOCK TABLE some-important-table" and leave for lunch. * leave a transaction open and go on vacation. Yeah, you can progressively lock down a system against all of these sorts of hazards, but it will get progressively less useful for anyone who wants to do actual work on it. In the end, the default settings have to represent a compromise that we think is generally useful. You're welcome to lock your own installation down more than that, but it doesn't follow that everybody else should too. regards, tom lane
