Re: refusing connections based on load ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vince Vielhaber <vev(at)michvhf(dot)com>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: refusing connections based on load ...
Date: 2001-04-26 14:26:38
Message-ID: 15765.988295198@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vince Vielhaber <vev(at)michvhf(dot)com> writes:
> On Wed, 25 Apr 2001, The Hermit Hacker wrote:
>> On Wed, 25 Apr 2001, Vince Vielhaber wrote:
>>
> On Wed, 25 Apr 2001, Tom Lane wrote:
> Because it's tied to a GNU getloadavg.c implementation, which we'd have
> license problems with using.
>
> It's part of the standard C library in FreeBSD. Any other platforms
> have it built in?
>>
>> As has been mentioned, Solaris and Linux also have it ...

> But what's in FreeBSD's standard library isn't GNU.

Obviously I confused some people. What Autoconf's LOADAVG macro
actually does is
(1) check to see if system has a getloadavg() library routine, and if
so, set up to use that. Otherwise
(2) apply a bunch of ad-hoc checks to find out whether a GNU-specific
getloadavg module can be used. That module isn't actually
included with autoconf; I imagine the one they have in mind is
the one in GNU make.

Therefore, Autoconf's macro is useless to us as a means of configuring
load average support, because we won't be using GNU make's getloadavg
module.

The Sendmail loadavg code should be more friendly from a licensing
standpoint, but IT HAS PRIVILEGE PROBLEMS. Reading /dev/kmem isn't
something that we should expect to be able to do in Postgres.

In short, I haven't seen any evidence that we have a portable solution
available. Please don't reply (yet again) "It works on $MYSYSTEM,
therefore there's no problem." If you want to implement this feature
then you need to take responsibility for making it work everywhere.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fernando Nasser 2001-04-26 14:26:48 Re: ERROR: parser: parse error at or near "JOIN"
Previous Message will trillich 2001-04-26 14:15:45 crypt(table.field) ?