[HACKERS] Added the word TODO in comments
This just so that somebody looking for TODO items in the source can find this one too. Regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com TODO.patch Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Doc bug
Gurjeet Singh wrote: cd pgsql/doc/src/sgml make html See http://developer.postgresql.org/pgdocs/postgres/docguide-build.html http://developer.postgresql.org/pgdocs/postgres/docguide-build.html This, obviously, isn't working on MinGW for me. I'll try Linux (Ubuntu). If you're doing it on windows, see http://people.planetpostgresql.org/mha/index.php?/archives/94-Building-the-PostgreSQL-docs-on-Windows.html#extended for some hints. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows installer and dlls
I uninstalled postgresql, removed the 5 files mentioned above from system32. When I installed 8.2.0 again, the installer reported that The installer has detected an incompatible version of OpenSSL installed in your system PATH. PostgreSQL requires OpenSSL 0.9.7 or later. If you remove your OpenSSL files (LIBEAY32.DLL and SSLEAY32.DLL) the installer will install the new version automatically.. However, during the second installation, none of the 5 files mentioned above were reinstalled in system32, only in the postgresql bin directory, as during the first installation. Is the report of the missing libeay32 and ssleay32 a superfluous leftover from the previous versions when these files were installed in system32? Are you sure they are not present in some *other* directory on your system that's in the PATH? //Magnus You're right. After they were removed from both C:\windows and C:\windows\system32 the installer did no longer report incompatible OpenSSL version. By the way: E.1.3.15. Win32 Port Allow MSVC to compile the PostgreSQL server (Magnus, Hiroshi Saito). Does this mean that the precompiled windows version of postgresql will be compiled by MSVC (I assume you can use the free 2005 express edition), or still by MinGW. I guess this will affect which compiler one should use for compilation of C-functions? Thanks, KP ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Windows installer and dlls
Knut P. Lehre wrote: I uninstalled postgresql, removed the 5 files mentioned above from system32. When I installed 8.2.0 again, the installer reported that The installer has detected an incompatible version of OpenSSL installed in your system PATH. PostgreSQL requires OpenSSL 0.9.7 or later. If you remove your OpenSSL files (LIBEAY32.DLL and SSLEAY32.DLL) the installer will install the new version automatically.. However, during the second installation, none of the 5 files mentioned above were reinstalled in system32, only in the postgresql bin directory, as during the first installation. Is the report of the missing libeay32 and ssleay32 a superfluous leftover from the previous versions when these files were installed in system32? Are you sure they are not present in some *other* directory on your system that's in the PATH? //Magnus You're right. After they were removed from both C:\windows and C:\windows\system32 the installer did no longer report incompatible OpenSSL version. By the way: E.1.3.15. Win32 Port Allow MSVC to compile the PostgreSQL server (Magnus, Hiroshi Saito). Does this mean that the precompiled windows version of postgresql will be compiled by MSVC (I assume you can use the free 2005 express edition), or still by MinGW. I guess this will affect which compiler one should use for compilation of C-functions? This is not decided yet. It is my hope that it will be, but since it's not on the buildfarm yet, we don't know. What we do know is that all point-releases in 8.0/8.1/8.2 will be built with MingW, we will absolutely not switch compiler until a new major version. //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] TODO: GNU TLS
Hi, I've just read most of that thread and found it rather disappointing. I'd just like to add my 2 (or 3) cents: a) I like to have the freedom to choose what software (under which licenses) I'm using. Thus I'd like to see GNUTLS supported, as it adds an additional feature to PostgreSQL per se: the option to choose between different SSL implementations. b) The other features of Martijn's patch got completely overseen. Can we (can you Martijn?) break up the patch into smaller pieces and discuss single independent features, like querying for parameters of the SSL connection? c) I'm disappointed at the way licenses are threated here. Being a developer myself, I'm looking at licenses as a wish of the author about how to treat his work and how to credit him. I'd like to follow these wishes as good as I can, instead of stepping into the grey-area and playing the 'hopefully-no-one-sues-us' game. In case of the advertising clause, which is very strong, IMO, I think most authors didn't want to be as strict as they made it sound in the license. Or did any of the OpenSSL or libjpeg projects ever try to sue somebody for not having mentioned them in their advertising materials? You can ask the authors how they really meant it, probably they will change the wording or even remove the advertising clause entirely. Or probably they officially state how they meant their advertising clause to be interpreted. (I'm not aware of the OpenSSL project doing so. While the FSF states quite clearly that they don't consider such a restriction to be respectful to their GPL.) Following that 'better-safe-than-sorry' philosophy, one could ask if PostgreSQL shouldn't better include the acknowledgements of OpenSSL (and MIT Kerberos) in all of their advertising materials... I fully understand and support Debian's point of view and I'd wish more people would follow that spirit. We'd have much less cases to fight for in curt and generally live in a better world (TM). Regards Markus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: GNU TLS
On Sun, Dec 31, 2006 at 03:25:42PM +0100, Markus Schiltknecht wrote: b) The other features of Martijn's patch got completely overseen. Can we (can you Martijn?) break up the patch into smaller pieces and discuss single independent features, like querying for parameters of the SSL connection? If I got a single ounce of feedback on them, sure. The only responses have involved the licence so far. I won't deny some of the other features were also controversial. In case of the advertising clause, which is very strong, IMO, I think most authors didn't want to be as strict as they made it sound in the license. Or did any of the OpenSSL or libjpeg projects ever try to sue somebody for not having mentioned them in their advertising materials? Please read the OpenSSL-GPL FAQ. They themselves acknowledge it's a problem, but claim they fall under the operating system exception, which is fine for everyone except the distributor of the operating system. http://www.openssl.org/support/faq.html#LEGAL2 They recommend that if you want to use OpenSSL, use a licence other than the GPL. Wikipedia also has more information about this. http://en.wikipedia.org/wiki/OpenSSL You can ask the authors how they really meant it, probably they will change the wording or even remove the advertising clause entirely. Or probably they officially state how they meant their advertising clause to be interpreted. (I'm not aware of the OpenSSL project doing so. While the FSF states quite clearly that they don't consider such a restriction to be respectful to their GPL.) The original authors have been asked and apparently can't be found or don't care. I strongly suggest you read the openssl archives before opening this can of worms. Note the authors involved are no longer part of OpenSSL, they have another SSL library, so they're probably not inclined to be nice. Following that 'better-safe-than-sorry' philosophy, one could ask if PostgreSQL shouldn't better include the acknowledgements of OpenSSL (and MIT Kerberos) in all of their advertising materials... AIUI all compiled distributions of postgresql using openssl do actually include such. For example the Windows Installer. I fully understand and support Debian's point of view and I'd wish more people would follow that spirit. We'd have much less cases to fight for in curt and generally live in a better world (TM). We're in the bizarre situation were both Debian and the OpenSSL groups beleive it is a problem, and postgresql does not. Quite odd. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] TODO: GNU TLS
On Sun, Dec 31, 2006 at 03:59:29PM +0100, Martijn van Oosterhout wrote: Please read the OpenSSL-GPL FAQ. They themselves acknowledge it's a problem, but claim they fall under the operating system exception, which is fine for everyone except the distributor of the operating system. http://www.openssl.org/support/faq.html#LEGAL2 They recommend that if you want to use OpenSSL, use a licence other than the GPL. I believe this to be a slight misrepresentation. The section before states The OpenSSL team does not offer legal advice. The section you quote then goes on to contradict this, by stating a position much more conservative than your summary: On many systems including the major Linux and BSD distributions, yes (the GPL does not place restrictions on using libraries that are part of the normal operating system distribution). On other systems, the situation is less clear. Some GPL software copyright holders claim that you infringe on their rights if you use OpenSSL with their software on operating systems that don't normally include OpenSSL. If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed. If you are using GPL software developed by others, you may want to ask the copyright holder for permission to use their software with OpenSSL. It seems your interpretation of the OpenSSL position is as questionable as your interpretation of the GPL, and what the GPL can legally require. :-) Nobody has proven an issue exists. The only way to prove it would be for an actual court case to set the precident. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] TODO: GNU TLS
It seems your interpretation of the OpenSSL position is as questionable as your interpretation of the GPL, and what the GPL can legally require. :-) Nobody has proven an issue exists. The only way to prove it would be for an actual court case to set the precident. Further, OpenSSL is not saying that an issue exists for them. They are saying that *some* people *may* have a problem with it. Can we all talk about things that matter now? Like improving table partitioning? At a minimum, please move this thread to -advocacy. Sincerely, Joshua D. Drake Cheers, mark -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO: GNU TLS
Hi, Martijn van Oosterhout wrote: Please read the OpenSSL-GPL FAQ. They themselves acknowledge it's a problem, but claim they fall under the operating system exception, which is fine for everyone except the distributor of the operating system. http://www.openssl.org/support/faq.html#LEGAL2 Thanks for the link. Unfortunately that FAQ does not say anything about the advertising clause or how they want it to be interpreted. They recommend that if you want to use OpenSSL, use a licence other than the GPL. ..which could be seen as a sign that they take their advertising clause serious. I wonder how much of their code is still copyrighted by authors refusing to remove that clause... Wikipedia also has more information about this. http://en.wikipedia.org/wiki/OpenSSL I also found this to be a good description: http://www.gnome.org/~markmc/openssl-and-the-gpl.html [ OT: Generally, I feel that the exceptions which are made to the GPL are very messy and confusing. And again, the exception implicitly states that the OpesSSL Projects wants you to adhere to the advertising clause. ] The original authors have been asked and apparently can't be found or don't care. I strongly suggest you read the openssl archives before opening this can of worms. Note the authors involved are no longer part of OpenSSL, they have another SSL library, so they're probably not inclined to be nice. Sure, I've heard about that and won't open that can of worms ;-) Following that 'better-safe-than-sorry' philosophy, one could ask if PostgreSQL shouldn't better include the acknowledgements of OpenSSL (and MIT Kerberos) in all of their advertising materials... AIUI all compiled distributions of postgresql using openssl do actually include such. For example the Windows Installer. The OpenSSL license speaks of all advertising materials mentioning .. use of this software. IMO, the PostgreSQL website matches that criterion very well, doesn't it? AFAICT, that's why so many people avoid advertising clauses like the plague. (And why it's called 'advertising clause' and not 'compiled distribution clause'.) Probably PostgreSQL should ask for an exception... ;-) We're in the bizarre situation were both Debian and the OpenSSL groups beleive it is a problem, and postgresql does not. Quite odd. I somehow don't understand how this could *not* be a problem. My reasoning is that one must not not respect authors wishes (licenses) very much if one feels this is not a problem. Regards Markus ---(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] Recent SIGSEGV failures in buildfarm HEAD
Tom Lane wrote: Seneca Cunningham [EMAIL PROTECTED] writes: I don't have a core, but here's the CrashReporter output for both of jackal's failed runs: Wow, some actual data, rather than just noodling about how to get it ... thanks! ... 11 postgres 0x0022b2e3 RelationIdGetRelation + 110 (relcache.c:1496) 12 postgres 0x00020868 relation_open + 84 (heapam.c:697) 13 postgres 0x0002aab9 index_open + 32 (indexam.c:140) 14 postgres 0x0002a9d4 systable_beginscan + 289 (genam.c:184) 15 postgres 0x002279e4 RelationInitIndexAccessInfo + 1645 (relcache.c:1200) 16 postgres 0x0022926a RelationBuildDesc + 3527 (relcache.c:866) 17 postgres 0x0022b2e3 RelationIdGetRelation + 110 (relcache.c:1496) 18 postgres 0x00020868 relation_open + 84 (heapam.c:697) 19 postgres 0x0002aab9 index_open + 32 (indexam.c:140) 20 postgres 0x0002a9d4 systable_beginscan + 289 (genam.c:184) 21 postgres 0x002279e4 RelationInitIndexAccessInfo + 1645 (relcache.c:1200) 22 postgres 0x0022926a RelationBuildDesc + 3527 (relcache.c:866) 23 postgres 0x0022b2e3 RelationIdGetRelation + 110 (relcache.c:1496) ... What you seem to have here is infinite recursion during relcache initialization. That's surely not hard to believe, considering I just whacked that code around, and indeed changed some of the tests that are intended to prevent such recursion. But what I don't understand is why it'd be platform-specific, much less not perfectly repeatable on the platforms where it does manifest. Anyone have a clue? fwiw - I can trigger that issue now pretty reliably on a fast Opteron box (running Debian Sarge/AMD64) with make regress in a loop - I seem to be able to trigger it in about 20-25% of the runs. the resulting core however looks totally stack corrupted and not really usable :-( Stefan ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] TODO: GNU TLS
Hi, [EMAIL PROTECTED] wrote: Nobody has proven an issue exists. The only way to prove it would be for an actual court case to set the precident. That's exactly the mentality that I'm questioning. Why always go to legal boundaries and ask for courts? Joshua D. Drake wrote: Further, OpenSSL is not saying that an issue exists for them. They are saying that *some* people *may* have a problem with it. Neither do they say that one can simply ignore their advertising clause and that everybody is save from being sued. And further, the OpenSSL license is not violated if OpenSSL in included in GPL software, the GPL license is. Thus it's probably quite irrelevant what the OpenSSL FAQ says about GPL violations. I agree that PostgreSQL (being BSD-like) should not care too much about the GPL. But we should care about the OpenSSL license, as they seem to take their advertising clause quite serious. At a minimum, please move this thread to -advocacy. I disagree, sorry. IMO, this is an important subject hackers should know about. (And it has nothing to do with PostgreSQL vs. the rest. Promotional ideas, etc., what -advocacy is said to be about.) Regards Markus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] A possible TODO item
Gurjeet Singh [EMAIL PROTECTED] writes: The comment above TOAST_INDEX_HACK in tuptoaster.h is: /* * This enables de-toasting of index entries. Needed until VACUUM is * smart enough to rebuild indexes from scratch. */ #define TOAST_INDEX_HACK Do we already have a TODO item to remove this hack? If not, I think there should be, because it is waiting for some other progress to happen. Like what? If you want to argue that it's important to work on, you'd better make the case for that. At first glance you might think that turning it off would Just Work, because VACUUM should always remove index entries before removing heap rows, but unfortunately an index might have more copies of a key than just the one in the directly associated index entry. (btree, for example, might have copied the key into a page high key and/or boundary keys in upper tree levels. Those copies will persist long after the underlying row is gone.) And surely we are never going to make VACUUM force a complete REINDEX as the comment suggests. So any change in the situation is going to require considerable work as well as some good ideas we haven't thought of yet. Plus, it's unclear that values large enough to require out-of-line storage are reasonable candidates for indexing in the first place. So: what's the argument that is going to persuade everyone that this is really important? 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] Added the word TODO in comments
Gurjeet Singh [EMAIL PROTECTED] writes: This just so that somebody looking for TODO items in the source can find this one too. If you're looking for TODO items, why wouldn't you be looking in the TODO document? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Recent SIGSEGV failures in buildfarm HEAD
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: fwiw - I can trigger that issue now pretty reliably on a fast Opteron box (running Debian Sarge/AMD64) with make regress in a loop - I seem to be able to trigger it in about 20-25% of the runs. the resulting core however looks totally stack corrupted and not really usable :-( Hmm, probably the stack overrun leaves the call stack too corrupt for gdb to make sense of. Try inserting check_stack_depth(); into one of the functions that're part of the infinite recursion, and then make check_stack_depth() do an abort() instead of just elog(ERROR). That might give you a core that gdb can work with. I'm still having absolutely 0 success reproducing it on a dual Xeon ... so it's not just the architecture that's the issue. Some kind of timing problem? That's hard to believe too. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Recent SIGSEGV failures in buildfarm HEAD
On Sun, Dec 31, 2006 at 05:43:45PM +0100, Stefan Kaltenbrunner wrote: Tom Lane wrote: What you seem to have here is infinite recursion during relcache initialization. That's surely not hard to believe, considering I just whacked that code around, and indeed changed some of the tests that are intended to prevent such recursion. But what I don't understand is why it'd be platform-specific, much less not perfectly repeatable on the platforms where it does manifest. Anyone have a clue? fwiw - I can trigger that issue now pretty reliably on a fast Opteron box (running Debian Sarge/AMD64) with make regress in a loop - I seem to be able to trigger it in about 20-25% of the runs. the resulting core however looks totally stack corrupted and not really usable :-( By reducing the stack size on jackal from the default of 8MB to 3MB, I can get this to trigger in roughly 30% of the runs while preserving the passed tests in the other parallel groups. -- Seneca [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] access method's algorithm authors
Hi, http://archives.postgresql.org/pgsql-committers/2005-11/msg00183.php this one removes the original algorithm name of access method from create_index.sqml. why? was that readded somewhere else? -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New version of money type
On Thu, 21 Dec 2006 10:47:52 -0500 Tom Lane [EMAIL PROTECTED] wrote: One bug I see in it is that you'd better make the alignment 'd' if the type is to be int8. Also I much dislike these changes: - int32 i = PG_GETARG_INT32(1); + int64 i = PG_GETARG_INT32(1); I changed this and a few other things. I didn't see any response to my question though. Shall I go ahead and commit now so that we can test in a wider setting? I haven't committed anything in years and I am hesitant to do so now without consencus. -- D'Arcy J.M. Cain darcy@druid.net | 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 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] access method's algorithm authors
Jaime Casanova [EMAIL PROTECTED] writes: http://archives.postgresql.org/pgsql-committers/2005-11/msg00183.php this one removes the original algorithm name of access method from create_index.sqml. why? It wasn't complete, up-to-date, or particularly helpful in context. was that readded somewhere else? src/backend/access/*/README are the appropriate places for citations of relevant papers. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] A possible TODO item
On 12/31/06, Tom Lane [EMAIL PROTECTED] wrote: Gurjeet Singh [EMAIL PROTECTED] writes: The comment above TOAST_INDEX_HACK in tuptoaster.h is: /* * This enables de-toasting of index entries. Needed until VACUUM is * smart enough to rebuild indexes from scratch. */ #define TOAST_INDEX_HACK Do we already have a TODO item to remove this hack? If not, I think there should be, because it is waiting for some other progress to happen. Like what? If you want to argue that it's important to work on, you'd better make the case for that. I haven't spent enough days in PGSQL-land that I can build a propaganda to support my viewpoint.It was just an impulse I got after reading the comments. I thought that if the author of the code (which, now I see, is you) wanted this hack to be removed at some point later, then it better be documented/mentioned in TODO list, albeit at low priority, so that we don't lose sight of it. At first glance you might think that turning it off would Just Work, That never crossed my mind. I haven't been able to dirty my hands enough with backend code that I can think along those lines yet; someday I'd like to be able to. When searching our archives, I saw a post ( http://archives.postgresql.org/pgsql-patches/2006-07/msg00101.php) mentioning this macro in include-files related problem, and that that eliminating it makes btree_gist to fail. because VACUUM should always remove index entries before removing heap rows, but unfortunately an index might have more copies of a key than just the one in the directly associated index entry. (btree, for example, might have copied the key into a page high key and/or boundary keys in upper tree levels. Those copies will persist long after the underlying row is gone.) And surely we are never going to make VACUUM force a complete REINDEX as the comment suggests. In that case, can the comment be changed! So any change in the situation is going to require considerable work as well as some good ideas we haven't thought of yet. Plus, it's unclear that values large enough to require out-of-line storage are reasonable candidates for indexing in the first place. So: what's the argument that is going to persuade everyone that this is really important? As I said, none; just that, if it is a pending work, it should be in the TODO list (low priority!!?), or have the comment changed, and... if this macro is indispensable it should be removed and the the code that it surrounds should be merged. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Re: [HACKERS] Added the word TODO in comments
The comment, This should be improved someday sure sounds like a TODO to me. I don't know if it should make it to the TODO doc, as that lists high-level/abstract feature-request-like items. Probably I should stop acting on impulse here. Hey, can someone around here lend me his rock!! ( no offence intended :) Best wishes to all in the new year... Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com On 12/31/06, Tom Lane [EMAIL PROTECTED] wrote: Gurjeet Singh [EMAIL PROTECTED] writes: This just so that somebody looking for TODO items in the source can find this one too. If you're looking for TODO items, why wouldn't you be looking in the TODO document? regards, tom lane
