Re: [HACKERS] EINTR error in SunOS
Greg Stark wrote: I would vote for the kernel, if the server didn't respond within 5 seconds, to simply return EIO. At least we know how to handle that... How do you handle it? By having Postgres shut down? And then the NFS server comes back and then what? Log the error if you can. Refuse new connections - until it is back up. Refuse or hang new queries - until it is back up. Retry? What should be done? -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Stats collector performance improvement
On 1/2/2006 3:20 PM, Tom Lane wrote: [ moving to -hackers ] Bruce Momjian writes: I did some research on this because the numbers Tom quotes indicate there is something wrong in the way we process stats_command_string statistics. [ ... proposed patch that seems pretty klugy to me ... ] I wonder whether we shouldn't consider something more drastic, like getting rid of the intermediate stats buffer process entirely. The original design for the stats communication code was based on the premise that it's better to drop data than to make backends wait on The original design was geared towards searching for useless/missing indexes and tuning activity like that. This never happened, but instead people tried to use it as a reliable debugging or access statistics aid ... which is fine but not what it originally was intended for. So yes, I think looking at what it usually is used for, a message passing system like SysV message queues (puke) or similar would do a better job. Jan the stats collector. However, as things have turned out I think this notion is a flop: the people who are using stats at all want the stats to be reliable. We've certainly seen plenty of gripes from people who are unhappy that backend-exit messages got dropped, and anyone who's using autovacuum would really like the tuple update counts to be pretty solid too. If we abandoned the unreliable-communication approach, could we build something with less overhead? regards, tom lane -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql & readline & win32
Tom Lane wrote: "Andrew Dunstan" <[EMAIL PROTECTED]> writes: The page links to this: http://www.gnu.org/licenses/license-list.html which lists the BSD licence without the advertising clause as a GPL-compatible free software license, of which it says: "This means you can combine a module which was released under that license with a GPL-covered module to make one larger program." You are misinterpreting the intent of that page completely. What the GNU people mean by "GPL compatible" is that you can combine GPL code with code licensed with a compatible license, and then redistribute the result UNDER THE GPL. (There are many licenses for which this is not so, and you basically couldn't redistribute such a combined work at all.) There is no situation in which they intend to let you redistribute combined works under the other license. Ok, I accept this. Their wording is certainly unfortunate, especuially when you combine it with what is said obn the redline home page. Incidentally, there is a place that libedit is being maintained, apparently: http://www.thrysoee.dk/editline/ Unfortunately, it doesn't seem to build on mingw :-( cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] EINTR error in SunOS
Martijn van Oosterhout writes: > The kernel is trying to be helpful by returning EINTR to say "ok, it > didn't complete. There's no error yet but it may yet work". Well it only returns EINTR if a signal was received. > With local hard drives if they don't respond, you assume they're broken. > When NFS servers don't respond you assume someone has temporarily pulled a > cable and it will come back soon. Huh? Well firstly with local hard drives you never get EINTR. Interrupts won't be delivered until after the syscall returns. You don't get EINTR because in the original BSD implementation it was more efficient to implement it that way and since disk i/o was always extremely fast it didn't threaten to delay your signals. You're mixing up operations timing out with signals being received. The reason you don't want NFS filesystem operations timing out (and you really don't) is that it's *possible* it will come back later. If you're the sysadmin and you're told your NFS server is down so you fix it and it comes back up properly you should be able to expect that the world returns to normal. If you have the "soft" option enabled then you now have to run around restarting every other service in your data center because you don't know which ones might have received an error and crashed. Worse, if any of those programs failed to notice the error (and they're not wrong to, traditionally certain operations never signaled errors) then your data is now corrupt. Some updates have been made but not others, and later updates may be based on the incorrect data. Now on the other hand the "intr" option is entirely reasonable to enable as long as you know you don't have software that doesn't expect it. It only kicks in if an actual signal is received, such as the user hitting C-c. Even if the server comes back 20m later the user isn't going to be upset that his C-c got handled. The only problem is that some software doesn't expect to get EINTR handles it poorly. > I would vote for the kernel, if the server didn't respond within 5 > seconds, to simply return EIO. At least we know how to handle that... How do you handle it? By having Postgres shut down? And then the NFS server comes back and then what? -- greg ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] EINTR error in SunOS
Martijn van Oosterhout writes: > I would vote for the kernel, if the server didn't respond within 5 > seconds, to simply return EIO. At least we know how to handle that... You can do this now by mounting 'soft' and setting the timeout appropriately. Whether it's really the best idea, well... -Doug ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql & readline & win32
"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > The page links to this: http://www.gnu.org/licenses/license-list.html which > lists the BSD licence without the advertising clause as a GPL-compatible > free software license, of which it says: "This means you can combine a > module which was released under that license with a GPL-covered module to > make one larger program." You are misinterpreting the intent of that page completely. What the GNU people mean by "GPL compatible" is that you can combine GPL code with code licensed with a compatible license, and then redistribute the result UNDER THE GPL. (There are many licenses for which this is not so, and you basically couldn't redistribute such a combined work at all.) There is no situation in which they intend to let you redistribute combined works under the other license. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] psql & readline & win32
On Monday 02 January 2006 18:21, Andrew Dunstan wrote:
> Tom Lane said:
> > "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> >> The readline home page at
> >> http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:
> >> Readline is free software, distributed under the terms of the GNU
> >> General Public License, version 2. This means that if you want to use
> >> Readline in a program that you release or distribute to anyone, the
> >> program must be free software and have a GPL-compatible license.
> >>
> >> Our BSD license is recognised as a GPL-compatible license.
> >
> > Whoever wrote that doesn't seem to have bothered to read the GPL. The
> > language of the GPL is exceedingly clear and specific:
>
> The page links to this: http://www.gnu.org/licenses/license-list.html which
> lists the BSD licence without the advertising clause as a GPL-compatible
> free software license, of which it says: "This means you can combine a
> module which was released under that license with a GPL-covered module to
> make one larger program."
>
yowza! Andrew you are reading that backwards. Those aren't licenses you can
combine gpl code with and be ok, those are licenses you can combine with gpl
code and release gpl products! Non-compatible free software licenses means
the free software license contains additional restrictions that make it
unacceptable to include in gpl code!! Oy vey!!!
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] psql & readline & win32
Tom Lane said: > "Andrew Dunstan" <[EMAIL PROTECTED]> writes: >> The readline home page at >> http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says: >> Readline is free software, distributed under the terms of the GNU >> General Public License, version 2. This means that if you want to use >> Readline in a program that you release or distribute to anyone, the >> program must be free software and have a GPL-compatible license. > >> Our BSD license is recognised as a GPL-compatible license. > > Whoever wrote that doesn't seem to have bothered to read the GPL. The > language of the GPL is exceedingly clear and specific: The page links to this: http://www.gnu.org/licenses/license-list.html which lists the BSD licence without the advertising clause as a GPL-compatible free software license, of which it says: "This means you can combine a module which was released under that license with a GPL-covered module to make one larger program." So in the highly unlikely event that we were challenged by the FSF we could point to that and say "we just did what your web site told us we could do." cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] psql & readline & win32
""Magnus Hagander"" <[EMAIL PROTECTED]> wrote > > Well, we should *at least* provide it from the source build. Since it > does work (with a small kludge, but it does work). > Me, I'm not fully happy with psql on win32. I want my tab completion! > (which the gui tools don't do either, from what I can tell. At least > pgadmin doesn't. Yet.) > Yeah, I am not against doing so and having more features is always cool! But I just suspect if we can afford the cost. Actually I tried a little bit on the "thrysoee" version you mentioned: $ ./config.guess i686-pc-mingw32 $./configure ... configure: error: libtermcap, libcurses or libncurses are required! This may give us a hint that port is not very easy though. Regards, Qingqing ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] psql & readline & win32
"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > The readline home page at > http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says: > Readline is free software, distributed under the terms of the GNU General > Public License, version 2. This means that if you want to use Readline in a > program that you release or distribute to anyone, the program must be free > software and have a GPL-compatible license. > Our BSD license is recognised as a GPL-compatible license. Whoever wrote that doesn't seem to have bothered to read the GPL. The language of the GPL is exceedingly clear and specific: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. It says THIS LICENSE. There is nothing at all about "compatible licenses" anywhere in the document. (Quote taken directly from the copy of the GPL in readline-4.2a.tar.gz.) > I really don't see that the Windows binary installer is any different from > the binary installers that most Linux distros have, and they are all linked > with readline. ... and they are all GPL-licensed. The fundamental problem here is that we don't want the Windows distribution of PG to become effectively GPL-licensed. There's no issue if someone builds their own copy and doesn't redistribute it, but there is a big issue if we are distributing a heavily used port in a way that violates someone else's license. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql & readline & win32
On Mon, 2 Jan 2006 16:27:48 -0600 (CST) "Andrew Dunstan" <[EMAIL PROTECTED]> wrote: > Our BSD license is recognised as a GPL-compatible license. Recognized by who? The only two entities that I can think of that matter would be GNU itself or the courts. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] psql & readline & win32
Greg Stark said: > Tom Lane <[EMAIL PROTECTED]> writes: > >> Robert Treat <[EMAIL PROTECTED]> writes: >> > On Sunday 01 January 2006 18:51, Andrew Dunstan wrote: >> >> This has been debated ad nauseam in the past. The consensus, bar a >> >> few people with more advanced paranoia than I suffer from, is that >> >> we can ;-) >> >> > I don't think it is good practice to ship packaged software that is >> > statically linked to a gpl library and then claim that your package >> > is bsd licensed. >> >> Robert is 100% right. > > I suspect Andrew was mixing up two different aspects of this. > > There isn't much dispute that shipping a binary linked (statically or > dynamically) with a library depends on your license to distribute > derivative works of that library. Ie, that Andrew's wrong and shipping > a binary linked with a GPL'd library is only legal if you follow the > terms of the GPL. > > There is controversy over whether the software that requires that > library becomes a derivative work itself. For example whether a Gimp > plugin that is useless without the Gimp would be a derivative work of > the Gimp itself and be undistributable unless you followed the Gimp > license terms. > > Most people do agree when the question is put for something like Gimp > plugins but seem to draw a distinction between that and things like > Postgres that happen to depend on linking with libreadline where > libreadline is a rather incidental part of the whole system. > > In RMS's view (and the view of the actual practicing lawyers who have > examined this question when real money was on the line, but then I > guess lawyers are paid well to have more advanced cases of paranoia > than Andrew) is that there's no such distinction in law and having > software that depends on libreadline is just as much bound by the GPL > as a Gimp plugin. > > But that said, in the case of a binary there's really no controversy. A > binary that's linked against libreadline clearly can't be legally > distributed without following the terms of the GPL. > First, note that readline is ONLY used in psql. So there is no question of GPL for most of our code. In any case, you don't have to GPL the code, as I understand it. The readline home page at http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says: Readline is free software, distributed under the terms of the GNU General Public License, version 2. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license. Our BSD license is recognised as a GPL-compatible license. OTOH, if I were a company distributing a closed source postgres distribution, I would probably not link my psql with readline. Interestingly, some Gnu software (e.g. bc) has the option of linking with readline or libedit. It's really a pity that libedit doesn't seem to be as well maintained. I really don't see that the Windows binary installer is any different from the binary installers that most Linux distros have, and they are all linked with readline. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Stats collector performance improvement
"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > AFAICS if we can maintain the stats counts solid, then it may hurt > performance dramatically. Think if we maintain > pgstat_count_heap_insert()/pgstat_count_heap_delete() pretty well, then we > get a replacement of count(*). Not at all. For one thing, the stats don't attempt to maintain per-transaction state, so they don't have the MVCC issues of count(*). I'm not suggesting any fundamental changes in what is counted or when. The two compromises that were made in the original stats design to make it fast were (1) stats updates lag behind reality, and (2) some updates may be missed entirely. Now that we have a couple of years' field experience with the code, it seems that (1) is acceptable for real usage but (2) not so much. And it's not even clear that we are buying any performance gain from (2), considering that it's adding the overhead of passing the data through an extra process. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Stats collector performance improvement
Ühel kenal päeval, E, 2006-01-02 kell 15:20, kirjutas Tom Lane: > [ moving to -hackers ] > > Bruce Momjian writes: > > I did some research on this because the numbers Tom quotes indicate there > > is something wrong in the way we process stats_command_string > > statistics. > > [ ... proposed patch that seems pretty klugy to me ... ] > > I wonder whether we shouldn't consider something more drastic, like > getting rid of the intermediate stats buffer process entirely. > > The original design for the stats communication code was based on the > premise that it's better to drop data than to make backends wait on > the stats collector. However, as things have turned out I think this > notion is a flop: the people who are using stats at all want the stats > to be reliable. We've certainly seen plenty of gripes from people who > are unhappy that backend-exit messages got dropped, and anyone who's > using autovacuum would really like the tuple update counts to be pretty > solid too. > > If we abandoned the unreliable-communication approach, could we build > something with less overhead? Weell, at least it should be non-WAL, and probably non-fsync, at least optionally . Maybe also inserts inserts + offline aggregator (instead of updates) to avoid lock contention. Something that collects data in blocks of local or per-backend shared memory in each backend and then gives complete blocks to aggregator process. Maybe use 2 alternating blocks per backend - 1 for ongoing stats collection and another given to aggregator. this has a little time shift, but will deliver accurate starts in the end. Things that need up-to-date stats (like pg_stat_activity), should look (and lock) also the ongoing satas collection blocks if needed (how do we know know the *if*) and delay each backend process momentaryly by looking. - Hannu ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Stats collector performance improvement
"Tom Lane" <[EMAIL PROTECTED]> wrote > > I wonder whether we shouldn't consider something more drastic, like > getting rid of the intermediate stats buffer process entirely. > > The original design for the stats communication code was based on the > premise that it's better to drop data than to make backends wait on > the stats collector. However, as things have turned out I think this > notion is a flop: the people who are using stats at all want the stats > to be reliable. We've certainly seen plenty of gripes from people who > are unhappy that backend-exit messages got dropped, and anyone who's > using autovacuum would really like the tuple update counts to be pretty > solid too. > AFAICS if we can maintain the stats counts solid, then it may hurt performance dramatically. Think if we maintain pgstat_count_heap_insert()/pgstat_count_heap_delete() pretty well, then we get a replacement of count(*). To do so, I believe that will add another lock contention on the target table stats. Regards, Qingqing ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Stats collector performance improvement
[ moving to -hackers ] Bruce Momjian writes: > I did some research on this because the numbers Tom quotes indicate there > is something wrong in the way we process stats_command_string > statistics. > [ ... proposed patch that seems pretty klugy to me ... ] I wonder whether we shouldn't consider something more drastic, like getting rid of the intermediate stats buffer process entirely. The original design for the stats communication code was based on the premise that it's better to drop data than to make backends wait on the stats collector. However, as things have turned out I think this notion is a flop: the people who are using stats at all want the stats to be reliable. We've certainly seen plenty of gripes from people who are unhappy that backend-exit messages got dropped, and anyone who's using autovacuum would really like the tuple update counts to be pretty solid too. If we abandoned the unreliable-communication approach, could we build something with less overhead? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > sorry for the false alarm, actually i can confirm that 2.5.31 (which is > the default flex on Sarge) is broken and 2.5.4 (available as flex-old) > DOES work. Using yyrestart() seems to work with both versions --- fix committed. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Stefan Kaltenbrunner wrote: > Tom Lane wrote: > >>"Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> >> >>>Not that hard to believe. 2.5.4 is what the major distributions are >>>shipping. >>>Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex >>>is now considered a NON-GNU project. >> >> >>No, the major reason for it is that flex 2.5.31 is seriously broken and >>non-compatible with its prior releases. I wasn't aware that they'd gone >>so far as to remove a documented macro (one that was documented in 2.5.4 >>as the *preferred* way to do things, mind you) but we already knew of >>several other issues with it. See the archives. >> >>I'll try to snarf a copy and see if there's a way to do it that's >>compatible with both releases, but it's the flex authors' own fault >>that 2.5.31 has had such poor uptake. > > > hmm it does not seem to work with the 2.5.4 version debian supplies as > "flex-old" too - maybe the following debian bug report(filed against > woody!) is related to this: sorry for the false alarm, actually i can confirm that 2.5.31 (which is the default flex on Sarge) is broken and 2.5.4 (available as flex-old) DOES work. Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql & readline & win32
Tom Lane <[EMAIL PROTECTED]> writes: > Robert Treat <[EMAIL PROTECTED]> writes: > > On Sunday 01 January 2006 18:51, Andrew Dunstan wrote: > >> This has been debated ad nauseam in the past. The consensus, bar a few > >> people with more advanced paranoia than I suffer from, is that we can ;-) > > > I don't think it is good practice to ship packaged software that is > > statically > > linked to a gpl library and then claim that your package is bsd licensed. > > Robert is 100% right. I suspect Andrew was mixing up two different aspects of this. There isn't much dispute that shipping a binary linked (statically or dynamically) with a library depends on your license to distribute derivative works of that library. Ie, that Andrew's wrong and shipping a binary linked with a GPL'd library is only legal if you follow the terms of the GPL. There is controversy over whether the software that requires that library becomes a derivative work itself. For example whether a Gimp plugin that is useless without the Gimp would be a derivative work of the Gimp itself and be undistributable unless you followed the Gimp license terms. Most people do agree when the question is put for something like Gimp plugins but seem to draw a distinction between that and things like Postgres that happen to depend on linking with libreadline where libreadline is a rather incidental part of the whole system. In RMS's view (and the view of the actual practicing lawyers who have examined this question when real money was on the line, but then I guess lawyers are paid well to have more advanced cases of paranoia than Andrew) is that there's no such distinction in law and having software that depends on libreadline is just as much bound by the GPL as a Gimp plugin. But that said, in the case of a binary there's really no controversy. A binary that's linked against libreadline clearly can't be legally distributed without following the terms of the GPL. -- greg ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > >>Not that hard to believe. 2.5.4 is what the major distributions are >>shipping. >>Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex >>is now considered a NON-GNU project. > > > No, the major reason for it is that flex 2.5.31 is seriously broken and > non-compatible with its prior releases. I wasn't aware that they'd gone > so far as to remove a documented macro (one that was documented in 2.5.4 > as the *preferred* way to do things, mind you) but we already knew of > several other issues with it. See the archives. > > I'll try to snarf a copy and see if there's a way to do it that's > compatible with both releases, but it's the flex authors' own fault > that 2.5.31 has had such poor uptake. hmm it does not seem to work with the 2.5.4 version debian supplies as "flex-old" too - maybe the following debian bug report(filed against woody!) is related to this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194904 Stefan ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Tom, On corgi (debian sarge) raq:~# bison -V bison (GNU Bison) 1.875a -- Original Message --- From: Tom Lane <[EMAIL PROTECTED]> To: pgsql-hackers@postgresql.org Sent: Mon, 02 Jan 2006 12:54:42 -0500 Subject: [HACKERS] What bison versions are installed on buildfarm machines? > Is there any way to find out $subject? I see that several of the > buildfarm machines are choking on a patch I committed yesterday: > > guc-file.l: In function `ProcessConfigFile': > guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this > function) > guc-file.l:162: error: (Each undeclared identifier is reported only once > guc-file.l:162: error: for each function it appears in.) > make[4]: *** [guc.o] Error 1 > > YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which > is the oldest version we officially support. But I'm prepared to change > it if there is another way that would work with a wider range of bison > versions. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster --- End of Original Message --- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] What bison versions are installed on buildfarm machines?
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Not that hard to believe. 2.5.4 is what the major distributions are > shipping. > Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex > is now considered a NON-GNU project. No, the major reason for it is that flex 2.5.31 is seriously broken and non-compatible with its prior releases. I wasn't aware that they'd gone so far as to remove a documented macro (one that was documented in 2.5.4 as the *preferred* way to do things, mind you) but we already knew of several other issues with it. See the archives. I'll try to snarf a copy and see if there's a way to do it that's compatible with both releases, but it's the flex authors' own fault that 2.5.31 has had such poor uptake. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Jon Jensen <[EMAIL PROTECTED]> writes: > On Mon, 2 Jan 2006, Tom Lane wrote: >> Can you demonstrate that this is actually a serious concern next to the >> total time spent launching a backend? I can't measure any real change >> in total time for "psql -l" when log_hostname is enabled, which should >> be a comparable hit. > The difference is negligible when using a UNIX socket (of course) or names > listed in /etc/hosts. But it's certainly slower in my tests if you really > use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s > without the DNS lookup for log_hostname, and 31.5s with. Or run as a > one-off, it's 0.032 to 0.041s. Um --- I was testing a local-loopback connection, but now that I look at the nsswitch.conf setup, it was going to /etc/hosts for that case. Coming across the network so that a real DNS lookup is forced, there seems to be a difference of about 4ms (note this is with a local DNS daemon). I don't think that's significant. If it is, you've got other performance problems anyway, and should switch to pooled connections to reduce the number of backend launches. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Tom Lane wrote: "Andrew Dunstan" <[EMAIL PROTECTED]> writes: configure doesn't actually report the bison version, but it does complain if the version is less than 1.875, and I don't see that on rook. Sigh, I haven't woken up entirely today :-( ... of course, this is a flex macro we are talking about, not bison. Our configure script does complain about flex 2.5.3, and I don't see that warning in rook's output, but perhaps some even older flex version is installed there? Hard to believe ... even 2.5.4 is pretty ancient. Not that hard to believe. 2.5.4 is what the major distributions are shipping. Even FC4 comes with 2.5.4a. The only reason I can see for this is that Flex is now considered a NON-GNU project. The currently supported Flex is up to 2.5.31. Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] EINTR error in SunOS
On Mon, Jan 02, 2006 at 08:55:47AM -0700, Doug Royer wrote: > > > Doug McNaught wrote: > > >c) treat EINTR as an I/O error (I don't know how easy this would be) > > So then at this point - it is detected, so problem solved? > > If a LOCAL hard drive fails to reply, you hang. Same with hard,intr > NFS file system. Not really. If a local hard drive fails to respond, the kernel times out the request and returns EIO to the app. That's the most annoying thing about NFS. At least even with reading bad floppies where the kernel keeps retrying, eventually the read() returns and you can cancel. With NFS, it never returns if the server never comes back. The kernel is trying to be helpful by returning EINTR to say "ok, it didn't complete. There's no error yet but it may yet work". With local hard drives if they don't respond, you assume they're broken. When NFS servers don't respond you assume someone has temporarily pulled a cable and it will come back soon. Huh? I would vote for the kernel, if the server didn't respond within 5 seconds, to simply return EIO. At least we know how to handle that... Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpVQleQRvmC0.pgp Description: PGP signature
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
On Mon, 2 Jan 2006, Tom Lane wrote: (1) What Tom proposed is that we store the hostname and do a new DNS lookup for every connection. That could be useful in certain situations, but I wouldn't use it for a busy production server. The additional time for DNS lookups (even with a fast local caching nameserver) would not be a price I'd want to pay for the convenience. Can you demonstrate that this is actually a serious concern next to the total time spent launching a backend? I can't measure any real change in total time for "psql -l" when log_hostname is enabled, which should be a comparable hit. The difference is negligible when using a UNIX socket (of course) or names listed in /etc/hosts. But it's certainly slower in my tests if you really use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s without the DNS lookup for log_hostname, and 31.5s with. Or run as a one-off, it's 0.032 to 0.041s. Enough to make a difference on a busy server taking connections only over a local network. However, if I consider the likely use cases, this feature probably isn't important to such highly speed-sensitive servers anyway. And for those who want every last bit of speed possible, /etc/hosts still allows them to use this feature without a noticeable speed penalty. If the documentation mentions that DNS lookups are done for every request if you choose to use hostnames in pg_hba.conf, I think that's fair enough. I started out proposing a one-line change. The odds of this ever getting done drop by an order of magnitude every time someone proposes another order-of-magnitude increase in the work required... It sounds like it's beyond a one-line change anyway, due to the possibility of multiple IP addresses coming back. But I agree that complicating this simple feature is overkill. The database is not a firewall, and doesn't have a firewall's speed due to connection overhead anyway. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ... ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>I just verified that -HEAD is broken on Debian Sarge 3.1 (nearly all of >>the failing buildfarm members are Debian Sarge 3.1 boxes) - and I just >>verified the Problem exists on i386 too. > > > What flex version are they using? flex 2.5.31 Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > I just verified that -HEAD is broken on Debian Sarge 3.1 (nearly all of > the failing buildfarm members are Debian Sarge 3.1 boxes) - and I just > verified the Problem exists on i386 too. What flex version are they using? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] What bison versions are installed on buildfarm machines?
"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > configure doesn't actually report the bison version, but it does complain if > the version is less than 1.875, and I don't see that on rook. Sigh, I haven't woken up entirely today :-( ... of course, this is a flex macro we are talking about, not bison. Our configure script does complain about flex 2.5.3, and I don't see that warning in rook's output, but perhaps some even older flex version is installed there? Hard to believe ... even 2.5.4 is pretty ancient. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Tom Lane wrote: > Is there any way to find out $subject? I see that several of the > buildfarm machines are choking on a patch I committed yesterday: > > guc-file.l: In function `ProcessConfigFile': > guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this > function) > guc-file.l:162: error: (Each undeclared identifier is reported only once > guc-file.l:162: error: for each function it appears in.) > make[4]: *** [guc.o] Error 1 > > YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which > is the oldest version we officially support. But I'm prepared to change > it if there is another way that would work with a wider range of bison > versions. I just verified that -HEAD is broken on Debian Sarge 3.1 (nearly all of the failing buildfarm members are Debian Sarge 3.1 boxes) - and I just verified the Problem exists on i386 too. The version of bison available on Debian Sarge reports as: bison (GNU Bison) 1.875d Written by Robert Corbett and Richard Stallman. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Jon Jensen <[EMAIL PROTECTED]> writes: > (1) What Tom proposed is that we store the hostname and do a new DNS > lookup for every connection. That could be useful in certain situations, > but I wouldn't use it for a busy production server. The additional time > for DNS lookups (even with a fast local caching nameserver) would not be a > price I'd want to pay for the convenience. Can you demonstrate that this is actually a serious concern next to the total time spent launching a backend? I can't measure any real change in total time for "psql -l" when log_hostname is enabled, which should be a comparable hit. I started out proposing a one-line change. The odds of this ever getting done drop by an order of magnitude every time someone proposes another order-of-magnitude increase in the work required... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
On 1/2/06, Jon Jensen <[EMAIL PROTECTED]> wrote: > On Sun, 1 Jan 2006, Andreas Pflug wrote: > > >>> While I haven't tried it, I suspect that allowing a DNS host name > >>> would take little work (basically removing the AI_NUMERICHOST flag > >>> passed to getaddrinfo in hba.c). There was once a good reason not > >>> to allow it: slow DNS lookups would lock up the postmaster. But > >>> now that we do this work in an already-forked backend, with an overall > >>> timeout that would catch any indefinite blockage, I don't see a good > >>> reason why we shouldn't let people use DNS names. > [snip] > > > > Routers/firewalls that allow DNS names will usually resolve them > > immediately, > > and store the IP addresses. > > I think it's a great idea to make DNS names an option in pg_hba.conf. > However, I think we're talking about two fairly different features here. > > (1) What Tom proposed is that we store the hostname and do a new DNS > lookup for every connection. That could be useful in certain situations, > but I wouldn't use it for a busy production server. The additional time > for DNS lookups (even with a fast local caching nameserver) would not be a > price I'd want to pay for the convenience. In a development environment, > it could be just the ticket, though. IMHO, this is the price you pay for using DNS. > > (2) As Andreas mentioned, firewalls commonly do the DNS lookups when they > read their configuration, and store the IP addresses. If we did this, > you'd presumably only have to reload the postmaster configuration to cause > the DNS lookups to be done again, but until then they'd be static and as > fast as using actual IP addresses. > > If both were implemented, I'm not sure how you'd indicate which method you > want on any given pg_hba.conf line. > > If we were only to have one of these, I'd prefer (2). You could always set > up a cron job to reload the postmaster config hourly or daily, to keep the > DNS lookups from getting too stale. If we're going to use an external facility, I'd vote for using it as a black box via the API it was designed with and not doing any caching tricks, especially if those tricks involve reloading the config file to make changes visible that would be seen if the facility were used "correctly". I guess I just see it as a "correct vs. fast" decision. If caching were to be used, expiry should be based on the TTL for the DNS record, and not a reload of our config. just my $0.02. > > Jon > > -- > Jon Jensen > End Point Corporation > http://www.endpoint.com/ > Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ... > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] What bison versions are installed on buildfarm machines?
Tom Lane said: > Is there any way to find out $subject? I see that several of the > buildfarm machines are choking on a patch I committed yesterday: > > guc-file.l: In function `ProcessConfigFile': > guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this > function) guc-file.l:162: error: (Each undeclared identifier is > reported only once guc-file.l:162: error: for each function it appears > in.) > make[4]: *** [guc.o] Error 1 > > YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which > is the oldest version we officially support. But I'm prepared to > change it if there is another way that would work with a wider range of > bison versions. > Some months ago we put in a feature that allows you to see the log of all stages, not just the stage that failed. Not all buildfarm members have yet been updated to that release, unfortunately, so you won't see it on every details page. Among those with this failure that have updated is rook. See the stage logs here: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=rook&dt=2006-01-02%2011:39:01 the "config" link is the config.log file configure produces, and the "configure" link is its stdout. configure doesn't actually report the bison version, but it does complain if the version is less than 1.875, and I don't see that on rook. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
On Sun, 1 Jan 2006, Andreas Pflug wrote: While I haven't tried it, I suspect that allowing a DNS host name would take little work (basically removing the AI_NUMERICHOST flag passed to getaddrinfo in hba.c). There was once a good reason not to allow it: slow DNS lookups would lock up the postmaster. But now that we do this work in an already-forked backend, with an overall timeout that would catch any indefinite blockage, I don't see a good reason why we shouldn't let people use DNS names. [snip] Routers/firewalls that allow DNS names will usually resolve them immediately, and store the IP addresses. I think it's a great idea to make DNS names an option in pg_hba.conf. However, I think we're talking about two fairly different features here. (1) What Tom proposed is that we store the hostname and do a new DNS lookup for every connection. That could be useful in certain situations, but I wouldn't use it for a busy production server. The additional time for DNS lookups (even with a fast local caching nameserver) would not be a price I'd want to pay for the convenience. In a development environment, it could be just the ticket, though. (2) As Andreas mentioned, firewalls commonly do the DNS lookups when they read their configuration, and store the IP addresses. If we did this, you'd presumably only have to reload the postmaster configuration to cause the DNS lookups to be done again, but until then they'd be static and as fast as using actual IP addresses. If both were implemented, I'm not sure how you'd indicate which method you want on any given pg_hba.conf line. If we were only to have one of these, I'd prefer (2). You could always set up a cron job to reload the postmaster config hourly or daily, to keep the DNS lookups from getting too stale. Jon -- Jon Jensen End Point Corporation http://www.endpoint.com/ Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ... ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] What bison versions are installed on buildfarm machines?
Is there any way to find out $subject? I see that several of the buildfarm machines are choking on a patch I committed yesterday: guc-file.l: In function `ProcessConfigFile': guc-file.l:162: error: `YY_FLUSH_BUFFER' undeclared (first use in this function) guc-file.l:162: error: (Each undeclared identifier is reported only once guc-file.l:162: error: for each function it appears in.) make[4]: *** [guc.o] Error 1 YY_FLUSH_BUFFER is documented as a standard macro in bison 1.875, which is the oldest version we officially support. But I'm prepared to change it if there is another way that would work with a wider range of bison versions. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] default resource limits
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: That's easily fixed, I think. We just need to remember what we have proved works. I can apply the attached patch if you think that's worth doing. If you like; but if so, remove the comment saying that there's a connection between the required list entries. done. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] EINTR error in SunOS
Doug McNaught wrote:
c) treat EINTR as an I/O error (I don't know how easy this would be)
So then at this point - it is detected, so problem solved?
If a LOCAL hard drive fails to reply, you hang. Same with hard,intr
NFS file system.
bytesRead = read(fd, buffer, requestedBytes);
if (bytesRead < 0) {
switch (errno) {
case EAGAIN:
#ifdef USING_RECORD_LOCKING_OR_NON_BLOCKING_IO
...do the above read() again...
#else
/*FALLTHRU*/
#endif
default:
... log error and errno...
break;
}
} else if (bytesRead == 0) {
...AT EOF...
} else if (bytesRead < requestdBytes) {
...if you care, loop on read until
remaining bytes are fetched
or at EOF...
}
return(bytesRead);
d) say "if you mount 'soft' and lose data, tough luck for you"
I seem to recall from my days at Sun, you should NOT use soft
mount for NFS writes at all. Soft mounts are for non-critical
disk resources. (Solaris admin manual?)
--
Doug Royer | http://INET-Consulting.com
---|-
We Do Standards - You Need Standards
begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;U.S.A
email;internet:[EMAIL PROTECTED]
title:CEO
tel;work:866-594-8574
tel;fax:866-594-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
MSN: [EMAIL PROTECTED]
Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [HACKERS] psql & readline & win32
Magnus Hagander writes: >> >2) Should we ship a file of standard bindings. We're not >> going to get it complete, but we could get some of the most >> common ones in europe at least (in sweden, this would for >> example include "[EMAIL PROTECTED]|"). Which would help people a lot. >> > >> > >> >> Yes we should, at least for Windows - put it in share along >> with other samples, maybe. > > That was my second question on that - where to put it, and how to find it. IMHO an elegant solution would be to expose readline's macro/bind mechanism with a psql command, e.g. like bash's "bind" does. This way one could put the macros into the system-wide psqlrc. regards, Andreas ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql & readline & win32
> >2) Should we ship a file of standard bindings. We're not > going to get it complete, but we could get some of the most > common ones in europe at least (in sweden, this would for > example include "[EMAIL PROTECTED]|"). Which would help people a lot. > > > > > > Yes we should, at least for Windows - put it in share along > with other samples, maybe. That was my second question on that - where to put it, and how to find it. > >3) How should the inputrc file be loaded. By default, you > have to type SET INPUTRC="\some\where\inputrc" before you > launch psql. But we could just as easily add: > >#if defined(WIN32) && defined(USE_READLINE) > > rl_read_init_file(our_path_to_inputrc); > >#endif > >to psql, making that step a whole lot easier. Especially for > people who launch psql from the startmenu, and can't specify > program-specific env vars. > > > > > > if user has $HOME/inputrc > load $HOME/inputrc > elsif exists $SYSTEMCONFIG/inputrc > load $SYSTEMCONFIG/inputrc > endif > > Since inputrc is meant to service many applications, we > shouldn't try to bypass that. Actually, I think readline handles that and we can't turn it off. Though I think I need to set INPUTRC= to make it work on win32, it doesn't know abuot the All Users profile for example. I was thinking of a completement to the inputrc. Which would be somethign like: if exists $SYSTEMCONFIG/psql.inputrc load $SYSTEMCONFIG/psql.inputrc endif if exists $HOME/inputrc<-- this part handled by readline, not us laod $HOME/inputrc <-- this part handled by readline, not us endif //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] psql & readline & win32
> > Anyone for trying to port BSD libedit to work on Windows? > > > > Maybe just let it be on Windows is acceptable. I am currently > happy with my psql without readline support on Windows, but > on Unix that's hard. If Windows users want more advanced > client, there are a bunch of GUI tools. Well, we should *at least* provide it from the source build. Since it does work (with a small kludge, but it does work). Me, I'm not fully happy with psql on win32. I want my tab completion! (which the gui tools don't do either, from what I can tell. At least pgadmin doesn't. Yet.) If we only allow it from build-from-source, it's no different from any other platform, license-wise. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] psql & readline & win32
> > I don't think it is good practice to ship packaged software that is > > statically linked to a gpl library and then claim that > your package > > is bsd licensed. If I were trying to use the windows > installer in a > > commercial application, I sure wouldn't want that liability. > > Why should we statically link it? > > How well maintained is libedit? I'd feel happier about a > switch if I could find a maintained home page for it. There appears to be more than one (!) There's one on http://sourceforge.net/projects/libedit/, and one on http://www.thrysoee.dk/editline/ at least. And http://www.s11n.net/editline/. And http://packages.qa.debian.org/e/editline.html. The second one supports cygwin, but not mingw. The first one I have no idea, but it has made no release since 2001 so it doesn't seem very active, whereas the second one made a release in oct 2005. I think the second one is the one the guy in the blog post I sent before was referring to, but I'm not sure. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] psql & readline & win32
-Original Message- From: [EMAIL PROTECTED] on behalf of Magnus Hagander Sent: Mon 1/2/2006 8:08 AM To: Tom Lane; Robert Treat Cc: pgsql-hackers@postgresql.org; Andrew Dunstan Subject: Re: [HACKERS] psql & readline & win32 > Though we do ship GPL stuff in it already - postgis to > be specific. But we don't link against that, we just > load the module at runtime... And of course, they *want* us to ship their code. The GNU folks most likely couldn't care less meaning they're far more likely to get annoyed if we unintentionally misinterpret the licence. Regards, Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Yes, it would be good to implement this. A warning about security and (possible) slow connections due to name resolution issues should be placed in the docs. Regards paolo elein <[EMAIL PROTECTED]> ha scritto > I also support this change. My clients have tended to move > machines and networks around a lot as well as move databases from machine > to machine. It would be nice to let the network gurus concentrate > on getting the dns servers up and correct and leverage that > work instead of having to change pg_hba.conf when these changes > occur. > > elein > [EMAIL PROTECTED] > > On Sun, Jan 01, 2006 at 01:30:46PM -0500, Tom Lane wrote: > > I was reminded of $subject by > > http://archives.postgresql.org/pgsql-admin/2006-01/msg2.php > > > > While I haven't tried it, I suspect that allowing a DNS host name > > would take little work (basically removing the AI_NUMERICHOST flag > > passed to getaddrinfo in hba.c). There was once a good reason not > > to allow it: slow DNS lookups would lock up the postmaster. But > > now that we do this work in an already-forked backend, with an overall > > timeout that would catch any indefinite blockage, I don't see a good > > reason why we shouldn't let people use DNS names. > > > > Thoughts? > > > > regards, tom lane > > > > ---(end of broadcast)--- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > >choose an index scan if your joining column's datatypes do not > >match > > > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq > ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql & readline & win32
-Original Message- From: [EMAIL PROTECTED] on behalf of Tom Lane Sent: Mon 1/2/2006 3:30 AM To: Robert Treat Cc: pgsql-hackers@postgresql.org; Andrew Dunstan; Magnus Hagander Subject: Re: [HACKERS] psql & readline & win32 > (Of course, you could also treat the Windows installer as being entirely > GPL-licensed, which would effectively comply with both upstream > licenses. But I don't find that an appealing solution.) Ain't gonna happen whilst pgAdmin is in there. The words 'over' and 'dead decaying corpse' spring to mind :-p Not to mention that we can't just change the licence anyway... /D ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql & readline & win32
-Original Message- From: [EMAIL PROTECTED] on behalf of Andrew Dunstan Sent: Sun 1/1/2006 11:51 PM To: Magnus Hagander Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] psql & readline & win32 > > > >4) Can we ship linked with readline in the installer? > > If not, can we ship a readline-linked binary at all, > > or just the source? Considering readline drags along > > the GPL, and not just the LGPL. (We can link either > > statically (default) or dynamically (separate package) > > to readline without problems, from what I can tell) > This has been debated ad nauseam in the past. The consensus, > bar a few people with more advanced paranoia than I suffer > from, is that we can ;-) The installer is a little different though, in that we would have to actually ship readline as part of the distro, as it's unlikely to be pre-installed on the OS. At best we would have to start shipping it's source as well, at worst it would make everything else in the package that uses it GPL as well. IANAL of course, but my self preservation instincts tell me to err on the side of caution. Regards, Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] psql & readline & win32
Robert Treat said: > On Sunday 01 January 2006 18:51, Andrew Dunstan wrote: >> Magnus Hagander wrote: >> >4) Can we ship linked with readline in the installer? If not, can we >> >ship >> > a readline-linked binary at all, or just the source? Considering >> > readline drags along the GPL, and not just the LGPL. (We can link >> > either statically (default) or dynamically (separate package) to >> > readline without problems, from what I can tell) >> >> This has been debated ad nauseam in the past. The consensus, bar a few >> people with more advanced paranoia than I suffer from, is that we can >> ;-) >> > > I don't think it is good practice to ship packaged software that is > statically linked to a gpl library and then claim that your package is > bsd licensed. If I were trying to use the windows installer in a > commercial application, I sure wouldn't want that liability. Why should we statically link it? How well maintained is libedit? I'd feel happier about a switch if I could find a maintained home page for it. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql & readline & win32
> Robert Treat <[EMAIL PROTECTED]> writes: > > On Sunday 01 January 2006 18:51, Andrew Dunstan wrote: > >> This has been debated ad nauseam in the past. The consensus, bar a > >> few people with more advanced paranoia than I suffer from, > is that we > >> can ;-) > > > I don't think it is good practice to ship packaged software that is > > statically linked to a gpl library and then claim that your > package is bsd licensed. > > Robert is 100% right. If the Readline people wanted non-GPL > packages linking to their code, they'd have used LGPL not > GPL. We must not ignore their clear intentions; to do so is > certainly unethical and probably illegal. Does it make a difference if we ship it dynamically linked against a DLL? Because we can do that pretty easily. > Anyone for trying to port BSD libedit to work on Windows? I googled a bit on that as well, and turns out that somebody did try it, and it wasn't easy. And from what I can tell, not complete yet. http://www.coldie.net/node/131 I'm sure it *can* be done, but it's probably quite a bit of work. > (Of course, you could also treat the Windows installer as > being entirely GPL-licensed, which would effectively comply > with both upstream licenses. But I don't find that an > appealing solution.) Me either. Though we do ship GPL stuff in it already - postgis to be specific. But we don't link against that, we just load the module at runtime... //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
