Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
readline hooks in our source tree could cause RMS/GNU to force us to a
GNU license.
Obviously, we could remove readline hooks and ship a BSD line editing
library, but does this make any sense to you? It doesn't make sense t
Bruce Momjian writes:
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
This sort of thing is complete nonsense.
By the same logic you could argue that the system("cp template1 ...")
> Bruce Momjian writes:
>
> > Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> > readline hooks in our source tree could cause RMS/GNU to force us to a
> > GNU license.
>
> This sort of thing is complete nonsense.
>
> By the same logic you could argue that the system("
On Sat, 23 Dec 2000, Bruce Momjian wrote:
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
>
> Obviously, we could remove readline hooks and ship a BSD line editing
> library, but do
> On Sat, 23 Dec 2000, Bruce Momjian wrote:
>
> > Rasmus Lerdorf, the big PHP developer, told me that the existence of GNU
> > readline hooks in our source tree could cause RMS/GNU to force us to a
> > GNU license.
> >
> > Obviously, we could remove readline hooks and ship a BSD line editing
> >
On Sat, 23 Dec 2000, Bruce Momjian wrote:
> OK, but does shipping our code with hooks obligate us? We don't ship
> readline.
Oh, oops. I didn't know readline wasn't in the postgres tree. Then,
obviously, distribution of .tar.gz does not obligate postgres to anything,
HOWEVER, the problem arises
Bruce Momjian wrote:
>
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
>
> Obviously, we could remove readline hooks and ship a BSD line editing
> library, but does this make any se
Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > >
> > > Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> > > readline hooks in our source tree could cause RMS/GNU to force us to a
> > > GNU license.
> > >
> > > Obviously, we could remove readline hooks and ship a BSD
* Bruce Momjian <[EMAIL PROTECTED]> [001223 06:59] wrote:
> Rasmus Lerdorf, the big PHP developer, told me that the existance of GNU
> readline hooks in our source tree could cause RMS/GNU to force us to a
> GNU license.
>
> Obviously, we could remove readline hooks and ship a BSD line editing
>
> FreeBSD has a freely available library called 'libedit' that could
> be shipped with postgresql, it's under the BSD license.
Yes, that is our solution if we have a real problem here.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, but does shipping our code with hooks obligate us?
It does not; if RMS thinks it does, he's full of it.
If push actually comes to shove, I'd simply remove the readline hooks,
but the entire issue is nonsense.
regards, tom l
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, but does shipping our code with hooks obligate us?
>
> It does not; if RMS thinks it does, he's full of it.
>
> If push actually comes to shove, I'd simply remove the readline hooks,
> but the entire issue is nonsense.
That is my opinion too.
Department of Things that Fell Through the Cracks:
Back in August we had concluded that it is a bad idea to trust
"sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
can safely open. FreeBSD was reported to return 4136, and I have
since noticed that LinuxPPC returns 1024. Bot
Tom Lane wrote:
>
> Department of Things that Fell Through the Cracks:
>
> Back in August we had concluded that it is a bad idea to trust
> "sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
> can safely open. FreeBSD was reported to return 4136, and I have
> since noticed t
Tom Lane writes:
> I'm not sure why this didn't get dealt with, but I think it's a "must
> fix" kind of problem for 7.1. The dbadmin has *got* to be able to
> limit Postgres' appetite for open file descriptors.
Use ulimit.
> I propose we add a new configuration parameter, MAX_FILES_PER_PROCESS
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I'm not sure why this didn't get dealt with, but I think it's a "must
>> fix" kind of problem for 7.1. The dbadmin has *got* to be able to
>> limit Postgres' appetite for open file descriptors.
> Use ulimit.
Even if ulimit exist
Maybe a setting that controls the total number of files that postmaster
plus backends can allocate among them would be useful. If you have a per
backend setting then that sort of assumes lots of clients with relatively
little usage. Which is probably true in many cases, but not in all.
--
Pete
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Maybe a setting that controls the total number of files that postmaster
> plus backends can allocate among them would be useful.
That'd be nice if we could do it, but I don't see any inexpensive way
to get one backend to release an open FD when anoth
> (1) A dbadmin who hasn't read the run-time configuration doc page (that
> you did such a nice job with) is going to have lots of performance
> issues besides this one.
>
> (2) The last thing *I* want to hear is stories of a default Postgres
> installation causing system-wide instability. But i
* Tom Lane <[EMAIL PROTECTED]> [001223 14:16] wrote:
> Department of Things that Fell Through the Cracks:
>
> Back in August we had concluded that it is a bad idea to trust
> "sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
> can safely open. FreeBSD was reported to return
> Department of Things that Fell Through the Cracks:
>
> Back in August we had concluded that it is a bad idea to trust
> "sysconf(_SC_OPEN_MAX)" as an indicator of how many files each backend
> can safely open. FreeBSD was reported to return 4136, and I have
> since noticed that LinuxPPC return
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> I propose we add a new configuration parameter, MAX_FILES_PER_PROCESS,
>> with a default value of about 100. A new backend would set its
>> max-files setting to the smaller of this parameter or
>> sysconf(_SC_OPEN_MAX).
> Seems nice idea. We have been
here's a post-mortem.
#0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
#1 0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0,
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234
#2
Brent Verner <[EMAIL PROTECTED]> writes:
> here's a post-mortem.
> #0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
> econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
Looks reasonable as far as it goes. Evidently the crash is in the
heap_getattr macro
On 24 Dec 2000 at 01:00 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > here's a post-mortem.
|
| > #0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
| > econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
|
| Looks reasonable as fa
Brent Verner <[EMAIL PROTECTED]> writes:
> (gdb) p *resSlot
> Error accessing memory address 0x40141830: Invalid argument.
Oooh. resSlot has been truncated to 32 bits --- judging by the other
nearby pointer values, it almost certainly should have been 0x140141830.
Now we have a lead.
I am guess
26 matches
Mail list logo
