On 15 August 2011 21:31, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I'd suggest that an appropriate interface would be an int GUC with a >> GucContext of PGC_SUSET, so that DBAs can impose system-wide limits. > > ... and that would be a seriously bad API. There are not SUSET > restrictions on other resources such as work_mem. Why do we need > one for this?
I think that there perhaps /should/ be optional SUSET restrictions on those resources, particularly work_mem (though I'd suggest a more sophisticated interface there) - I haven't argued for that because, respectfully, I already know that to do so would be pretty close to futile. I have argued for this because I think that an important distinction can be drawn that might convince those who'd reject the idea of "poor man's admission control". The distinction is that the only way that we'll ever be able to guard against this sort of failure is with an approach that is essentially equivalent to my proposal - stop trying after some arbitrary number of some unit of work. I'm sure that you don't need me to tell you that it has already been proven that solving the halting problem is impossible. What you may not be aware of is the fact that a proof exists for PG rCTE's Turing completeness. Consequently, I think that "solving the halting problem" is the barrier to coming up with something fundamentally better. I don't think that your scepticism about the general need to have such protection is justified; I believe that there is plenty of anecdotal evidence out there that this is useful in larger commercial contexts, and I've already named some places where a person might look for such anecdotal evidence. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers