[HACKERS] Re: 7.1 on DEC/Alpha
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 guessing that the truncation happened somewhere in executor/functions.c, but don't see it right away... regards, tom lane
[HACKERS] Re: Re: 7.1 on DEC/Alpha
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 far as it goes. Evidently the crash is in the
| heap_getattr macro call at line 1096 of src/backend/executor/execQual.c.
| We need to look at the data structures that macro uses.
| What do you get from
|
| p *fselect
$1 = {type = T_FieldSelect, arg = 0x140169d40, fieldnum = 1, resulttype = 25,
resulttypmod = -1}
| p *econtext
$2 = {type = T_ExprContext, ecxt_scantuple = 0x14016a568,
ecxt_innertuple = 0x0, ecxt_outertuple = 0x0,
ecxt_per_query_memory = 0x1400c5df0, ecxt_per_tuple_memory = 0x1400c6670,
ecxt_param_exec_vals = 0x0, ecxt_param_list_info = 0x140141760,
ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
| p *resSlot->val
Error accessing memory address 0x40141838: Invalid argument.
| p *resSlot->ttc_tupleDescriptor
Error accessing memory address 0x40141848: Invalid argument.
additionally:
(gdb) p result
$4 = 1075058736
(gdb) p *resSlot
Error accessing memory address 0x40141830: Invalid argument.
| BTW, if you didn't configure with --enable-cassert, it'd be a good idea
| to go back and try it that way...
will reconfig/rebuild shortly.
brent
Re: [HACKERS] Re: 7.1 on DEC/Alpha
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 call at line 1096 of src/backend/executor/execQual.c. We need to look at the data structures that macro uses. What do you get from p *fselect p *econtext p *resSlot->val p *resSlot->ttc_tupleDescriptor BTW, if you didn't configure with --enable-cassert, it'd be a good idea to go back and try it that way... regards, tom lane
[HACKERS] Re: 7.1 on DEC/Alpha
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 0x1200cdd74 in ExecEvalFuncArgs (fcache=0x14016aa70, argList=0x14016a030, econtext=0x14016a030) at execQual.c:603 #3 0x1200cde54 in ExecMakeFunctionResult (fcache=0x14016aa70, arguments=0x1401616d0, econtext=0x14016a030, isNull=0x11fffdf88 "", isDone=0x0) at execQual.c:654 #4 0x1200ce224 in ExecEvalOper (opClause=0x1401615f0, econtext=0x14016a030, isNull=0x11fffdf88 "", isDone=0x0) at execQual.c:841 #5 0x1200cea24 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1204 #6 0x1200cec54 in ExecQual (qual=0x14016a1a0, econtext=0x14016a030) at execQual.c:1356 #7 0x1200cf2a8 in ExecScan (node=0x14016a1d0, accessMtd=0x1200d8320 ) at execScan.c:129 #8 0x1200d846c in ExecSeqScan (node=0x1401615f0) at nodeSeqscan.c:138 #9 0x1200cc280 in ExecProcNode (node=0x14016a1d0, parent=0x14016a1d0) at execProcnode.c:284 #10 0x1200ca8c0 in ExecutePlan (estate=0x14016a310, plan=0x14016a1d0, numberTuples=1, direction=ForwardScanDirection, destfunc=0x140020c20) at execMain.c:959 #11 0x1200c9b50 in ExecutorRun (queryDesc=0x1401615f0, estate=0x14016a310, count=0) at execMain.c:199 #12 0x1200d1140 in postquel_getnext (es=0x140160630) at functions.c:324 #13 0x1200d1300 in postquel_execute (es=0x140160630, fcinfo=0x1401604a0, fcache=0x140160590) at functions.c:417 #14 0x1200d14d8 in fmgr_sql (fcinfo=0x1401604a0) at functions.c:542 #15 0x1200ce09c in ExecMakeFunctionResult (fcache=0x140160480, arguments=0x14015e810, econtext=0x140119cd0, isNull=0x140160350 "", isDone=0x11fffe258) at execQual.c:712 #16 0x1200ce2c4 in ExecEvalFunc (funcClause=0x1401615f0, econtext=0x140119cd0, isNull=0x140160350 "", isDone=0x11fffe258) at execQual.c:883 #17 0x1200cea3c in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1208 #18 0x1200c8e10 in ExecEvalIter (iterNode=0x1401615f0, econtext=0x14016a030, isNull=0x1 , isDone=0x0) at execFlatten.c:56 #19 0x1200ce9b0 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1183 #20 0x1200cdd74 in ExecEvalFuncArgs (fcache=0x140160290, argList=0x14016a030, econtext=0x140119cd0) at execQual.c:603 #21 0x1200cde54 in ExecMakeFunctionResult (fcache=0x140160290, arguments=0x14015e840, econtext=0x140119cd0, isNull=0x11fffe3a0 "", isDone=0x11fffe468) at execQual.c:654 #22 0x1200ce2c4 in ExecEvalFunc (funcClause=0x1401615f0, econtext=0x140119cd0, isNull=0x11fffe3a0 "", isDone=0x11fffe468) at execQual.c:883 #23 0x1200cea3c in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1208 #24 0x1200ce574 in ExecEvalFieldSelect (fselect=0x14015e720, econtext=0x14016a030, isNull=0x11fffe3a0 "", isDone=0x0) at execQual.c:1091 #25 0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234 #26 0x1200c8e10 in ExecEvalIter (iterNode=0x1401615f0, econtext=0x14016a030, isNull=0x1 , isDone=0x0) at execFlatten.c:56 #27 0x1200ce9b0 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1183 #28 0x1200ceea4 in ExecTargetList (targetlist=0x14015e870, targettype=0x14016, values=0x140160260, econtext=0x140119cd0, isDone=0x11fffe5a8) at execQual.c:1528 #29 0x1200cf1a8 in ExecProject (projInfo=0x0, isDone=0x1) at execQual.c:1751 #30 0x1200d8074 in ExecResult (node=0x14015e5b0) at nodeResult.c:167 #31 0x1200cc238 in ExecProcNode (node=0x14015e5b0, parent=0x14015e5b0) at execProcnode.c:272 #32 0x1200ca8c0 in ExecutePlan (estate=0x14015eab0, plan=0x14015e5b0, numberTuples=0, direction=ForwardScanDirection, destfunc=0x1401603a0) at execMain.c:959 #33 0x1200c9b50 in ExecutorRun (queryDesc=0x1401615f0, estate=0x14015eab0, count=0) at execMain.c:199 #34 0x12013e5c0 in ProcessQuery (parsetree=0x14015ea80, plan=0x14016) at pquery.c:305 #35 0x12013c568 in pg_exec_query_string ( query_string=0x140115310 "SELECT p.hobbies.equipment.name, p.hobbies.name, p.name FROM person* p;", parse_context=0x1400c5c60) at postgres.c:817 #36 0x12013dd10 in PostgresMain (argv=0x11fffe9a8, real_argv=0x11ae8, username=0x1400b72f9 "pgadmin") at postgres.c:1827 #37 0x12011aef0 in DoBackend (port=0x1400b7080) at postmaster.c:2021 #38 0x12011a888 in BackendStartup (port=0x1400b7080) at postmaster.c:1798 #39 0x12011938c in ServerLoop () at postmaster.c:957 #40 0x120118c10 in PostmasterMain (argv=0x11ae8) at postmaster.c:664 #41 0x1200e5980 in main (argv=0x11ae8) at main.c:138
Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)
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 heard lots of problem reports caused by > ruuning out of the file table. > However it would be even nicer, if it could be configurable at runtime > (at the postmaster starting up time) like -N option. Yes, what I meant was a GUC parameter named MAX_FILES_PER_PROCESS. You could set it via postmaster.opts or postmaster command line switch. regards, tom lane
Re: [HACKERS] Re: Too many open files (was Re: spinlock problemsreported earlier)
> 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. Both of those are > unreasonably large fractions of the actual kernel file table size. > A few dozen backends opening hundreds of files apiece will fill the > kernel file table on most Unix platforms. > > 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. > > 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 heard lots of problem reports caused by ruuning out of the file table. However it would be even nicer, if it could be configurable at runtime (at the postmaster starting up time) like -N option. Maybe MAX_FILES_PER_PROCESS can be a hard limit? -- Tatsuo Ishii
Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)
* 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 4136, and I have > since noticed that LinuxPPC returns 1024. Both of those are > unreasonably large fractions of the actual kernel file table size. > A few dozen backends opening hundreds of files apiece will fill the > kernel file table on most Unix platforms. getdtablesize(2) on BSD should tell you the per-process limit. sysconf on FreeBSD shouldn't lie to you. getdtablesize should take into account limits in place. later versions of FreeBSD have a sysctl 'kern.openfiles' which can be checked to see if the system is approaching the systemwide limit. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reportedearlier)
> (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 if we don't insert > an open-files limit that's tighter than the "customary operating system > limit", that's exactly the situation we have, at least on several > popular platforms. IMHO, let's remember we keep a cache of file descriptors open for performance. How many file do we really need open in the cache? I can't imagine any performance reason to have hundreds of open file descriptors cached. A file open is not that big a deal. Just because the OS says we can open 1000 files doesn't mean we should open them just to keep a nice cache. We are keeping them open just for performance reasons, not because we actually need them to get work done. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)
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 another one needs one. So, divvying up the limit on an N-per-backend basis seems like the most workable approach. regards, tom lane
Re: [HACKERS] Re: Too many open files (was Re: spinlock problemsreported earlier)
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. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)
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 exists and is able to control that parameter on a given platform (highly unportable assumptions), it's not really a workable answer. fd.c has to stop short of using up all of the actual nfile limit, or else stuff like the dynamic loader is likely to fail. > I think this is an unreasonable interference with the customary operating > system interfaces (e.g., ulimit). The last thing I want to hear is > "Postgres is slow and it only opens 100 files per process even though I > to allow 32 million." (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 if we don't insert an open-files limit that's tighter than the "customary operating system limit", that's exactly the situation we have, at least on several popular platforms. regards, tom lane
Re: [HACKERS] Re: Too many open files (was Re: spinlock problemsreported earlier)
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, > 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). I think this is an unreasonable interference with the customary operating system interfaces (e.g., ulimit). The last thing I want to hear is "Postgres is slow and it only opens 100 files per process even though I to allow 32 million." -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)
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 that LinuxPPC returns 1024. Both of those are > unreasonably large fractions of the actual kernel file table size. > A few dozen backends opening hundreds of files apiece will fill the > kernel file table on most Unix platforms. > > 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. > > 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). > > An alternative approach would be to make the parameter be total open files > across the whole installation, and divide it by MaxBackends to arrive at > the per-backend limit. However, it'd be much harder to pick a reasonable > default value if we did it that way. > > Comments? On Linux, at least, the 1024 file limit is a per process limit, the system wide limit defaults to 4096 and can be easily changed by echo 16384 > /proc/sys/fs/file-max (16384 is arbitrary and can be much larger) I am all for having the ability to tune behavior over the system reported values, but I think it should be an option which defaults to the previous behavior. -- http://www.mohawksoft.com
Re: [HACKERS] Re: Too many open files (was Re: spinlock problems reported earlier)
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. Both of those are unreasonably large fractions of the actual kernel file table size. A few dozen backends opening hundreds of files apiece will fill the kernel file table on most Unix platforms. 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. 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). An alternative approach would be to make the parameter be total open files across the whole installation, and divide it by MaxBackends to arrive at the per-backend limit. However, it'd be much harder to pick a reasonable default value if we did it that way. Comments? regards, tom lane
Re: [HACKERS] GNU readline and BSD license
> 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. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] GNU readline and BSD license
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 lane
Re: [HACKERS] GNU readline and BSD license
> 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) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] GNU readline and BSD license
* 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 > library, but does this make any sense to you? It doesn't make sense to > me, but he was quite certain. > > Our ODBC library is also GNU licensed, but I am told this is not a > problem because it doesn't link into the backend. However, neither does > readline. However, readline does link into psql. FreeBSD has a freely available library called 'libedit' that could be shipped with postgresql, it's under the BSD license. If you have access to a FreeBSD box see the editline(3) manpage, or go to: http://www.freebsd.org/cgi/man.cgi?query=editline&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
[HACKERS] Re: GNU readline and BSD license
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 line editing > > > library, but does this make any sense to you? It doesn't make sense to > > > me, but he was quite certain. > > > > > > Our ODBC library is also GNU licensed, but I am told this is not a > > > problem because it doesn't link into the backend. However, neither does > > > readline. However, readline does link into psql. > > > > Readline is LGPL is it not? If you are merely linking to a shared > > library assumed to be on the system, and do not actually incorporate > > readline code within psql, you should be fine. > > According to him, it is GPL, not LGPL, and looking at the COPYING file > in readline, it seems he is correct. Wow, I never noticed that, I always assumed it was LGPL. Anyway, it makes no difference. Under Terms and conditions: (1) Postgres does not distribute readline as part of the source, the user must obtain it themselves. (2) Postgres does not alter or include the readline library does it? If so, you would have to share your changes. There is an important paragraph: >> In addition, mere aggregation of another work not based on the Program >> with the Program (or with a work based on the Program) on a volume of >> a storage or distribution medium does not bring the other work under >> the scope of this License. (3) Postgres already distributes source, although it does not appear that is required. pgsql inc's desire to have a two year closed source, they would have to make sure they made available any changes they make to GNU source. (4) Again Postgres does not distribute readline, so no problem. (5) The postgres team neither modifies or distributes the readline code. (section 5) The rest Do not seem to apply. -- http://www.mohawksoft.com
Re: [HACKERS] GNU readline and BSD license
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 sense to you? It doesn't make sense to > me, but he was quite certain. > The sole psql program could be GNU-licenced... just my 2p. Fabrice
Re: [HACKERS] GNU readline and BSD license
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 with distribution of binaries (.rpm and others) which are linked against libreadline _statically_ (basically, we can't do it). Our RPM distrib is linked dynamically, but I don't know about other binaries... >From my understanding of GPL, if it is linked dynamically, we are exempt since it does not constitute a 'derived package'. -alex
Re: [HACKERS] GNU readline and BSD license
> 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 > > library, but does this make any sense to you? It doesn't make sense to > > me, but he was quite certain. > Unfortunately he's right, since GPL software is incompatible with any > non-GPL software. Stallman publicly admitted that he intentionally > released readline under GPL, not LGPL, to force more people into GPLing > their code. OK, but does shipping our code with hooks obligate us? We don't ship readline. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] GNU readline and BSD license
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 does this make any sense to you? It doesn't make sense to > me, but he was quite certain. Unfortunately he's right, since GPL software is incompatible with any non-GPL software. Stallman publically admitted that he intentionally released readline under GPL, not LGPL, to force more people into GPLing their code.
Re: [HACKERS] GNU readline and BSD license
> 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 ...")
> calls could force us to a GNU license, because 'cp' is from GNU fileutils.
Well, his issue was that 'cp' is not in the binary, while readline
_could_ be in the binary. My issue is that we only optionally link
in the library. We don't actually ship the library with our code.
Honestly, it made no sense to me either, and if it hadn't been Rasmus, I
would have written it off immediately.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] GNU readline and BSD license
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 ...")
calls could force us to a GNU license, because 'cp' is from GNU fileutils.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] GNU readline and BSD license
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 to me, but he was quite certain. Our ODBC library is also GNU licensed, but I am told this is not a problem because it doesn't link into the backend. However, neither does readline. However, readline does link into psql. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
