On Wed, 25 Apr 2001, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > A conncurrent-xacts limit isn't perfect of course, but I think it'd
> > be pretty good, and certainly better than anything based on the
> > available load-average numbers.
>
> The concurrent transaction limit would allow you to control the absolute
> load of the PostgreSQL server, but we can already do that and it's not
> what we're after here. The idea behind the load average based approach is
> to make the postmaster respect the situation of the overall system.
> Additionally, the concurrent transaction limit would only be useful on
> setups that have a lot of idle transactions. Those setups exist, but not
> everywhere.
>
> To me, both of these approaches are in the "if you don't like it, don't
> use it" category.
Agreed ... by default, the loadavg method could be set to zero, to ignore
... I don't care if I'm off by 1min before I catch the increase, the fact
is that I have caught it, and prevent any new ones coming in until it
drops off again ...
Make it two variables:
transla
rejectla
if transla is hit, restrict on transactions, letting others connect, but
putting them on hold while the la drops again ... if it goes above
rejectla, refuse new connections altogether ...
so now I can set something like:
transla = 8
rejectla = 16
but if loadavg goes above 16, I want to get rid of what is causing the
load to rise *before* adding new variables to the mix that will cause it
to rise higher ...
and your arg about permissions (Tom's, not Peter's) is moot in at least 3
of the major systems (Linux, *BSD and Solaris) as there is a getloadavg()
function in all three for doing this ...
