Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: This is *not* going in the right direction :-( Well, then show me what direction you think is better. Fewer restrictions, not more. The thrust of what I've been saying (and I think Roman too) is to trust in the hardware float-arithmetic implementation to be right. Every time you add an additional error check you are going in the wrong direction. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: GNU TLS
On 12/29/06, Stephen Frost wrote: So, Debian is distributing an application (exim4 w/ libpq libssl) which includes GPL code (exim4) combined with code under another license (BSD w/ advertising clause) which *adds additional restrictions* (the advertising clause) over those in the GPL, which is against the terms of the GPL. It's *Debian's* problem, but *PostgreSQL* can solve it by providing the option to link against GNUTLS instead. In the case above, exim4 *can* provide an exception because it's the *GPL* of *exim4* which is being violated by the advertising clause in the *OpenSSL* license. Which exim4 upstream has *done*, and which can be seen in their license (linked to previously in this thread). Considering that the problem is caused by the choice for a license so restrictive it prohibits linking to OpenSSL, I think a license exception in said restrictive license is exactly the right way for Debian to solve their problem. Jochem ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] WITH support
Hello, I can see : WITH RECURSIVE hierarchical queries (Jonah H. Harris) in : http://developer.postgresql.org/index.php/Todo:WishlistFor83 GREAT!!! Such feature is very important, because it is supported in most of commercial database SQL Server 2003 support WITH RECURSIVE DB2 support it too (WITH RECURSIVE has been invented by IBM) Oracle support CONNECT BY (which is not standard, but very easier to use compare to WITH RECURSIVE) PostGreSQL would be the first opensource database supporting hierarchical queries... Today we use the CONNECT BY patch made by evgen potemkin http://gppl.moonbone.ru/, it works well on 8.1... But we are ready to drop it if WITH RECURSIVE is integrated!!! It would be great to open a page on the developper wiki on this subject? Sincerely Hubert FONGARNAND _ _ __ _ _ __ __ _ | ___(_) __| |_ _ ___(_) __ _| | / ___|| |_ __ _ / _|/ _(_)_ __ __ _ | |_ | |/ _` | | | |/ __| |/ _` | | \___ \| __/ _` | |_| |_| | '_ \ / _` | | _| | | (_| | |_| | (__| | (_| | | ___) | || (_| | _| _| | | | | (_| | |_| |_|\__,_|\__,_|\___|_|\__,_|_| |/ \__\__,_|_| |_| |_|_| |_|\__, | |___/ Le jeudi 28 décembre 2006 à 22:52 -0500, Bruce Momjian a écrit : Edwin Ramirez wrote: Hello, What is the status of supporting the WITH keyword? I see these TODO items: * Add SQL99 WITH clause to SELECT * Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT Are they the same item? Someone has said they will do RECURSIVE for 8.3, but there is no guarantee. ___ Ce message et les �ventuels documents joints peuvent contenir des informations confidentielles. Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce message non conforme � sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de ce message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue pour responsable de son contenu.
Re: [HACKERS] effective_cache_size vs units
JCN == Jim C Nasby [EMAIL PROTECTED] writes: JCN Truth is, I bet many (if not most) DBAs barely know that case JCN matters in the units. Sounds like the school system needs fixing, then. /Benny ---(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
On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote: Stephen, let me explain *exactly* why I think this is horsepucky. libjpeg, my other major open-source project, has always been shipped under a BSD-ish license that includes an advertising clause; I quote: : (2) If only executable code is distributed, then the accompanying : documentation must state that this software is based in part on the work of : the Independent JPEG Group. That's not an advertising clause, that merely asks that it be mentioned somewhere in the documentation, which is copied along with the rest of the code, so that's not limiting the redisitribution of anything. It also only applies when the source is not distributed, which means for the GPL it's a total non-issue. The OpenSSL licence on the other hand wants any advertising material of any application mentioning the use of SSL to include the acknowledgement. This would include flyers printed for a conference, or the label of the CD that contains it. Surely you can see the difference? Curiously, every single GPL-license web browser in the world uses libjpeg. Until I see a widespread willingness to remove JPEG support in GPL-licensed software, and/or somebody providing a pure-GPL replacement for libjpeg, I am not going to take this argument seriously. There is exactly zero meaningful difference between the libjpeg license terms and the OpenSSL terms, but where is the pushback on libjpeg? I have not seen any, in all the years I worked on that project. Because there is a very large, very meaningful difference. 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] WITH support
On Thu, Dec 28, 2006 at 10:52:45PM -0500, Bruce Momjian wrote: Edwin Ramirez wrote: Hello, What is the status of supporting the WITH keyword? I see these TODO items: * Add SQL99 WITH clause to SELECT * Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT Are they the same item? Not exactly. There is a WITH in the SQL:2003 spec (T121 and T122) which doesn't include RECURSIVE, but they're related to the RECURSIVE one (T131). Someone has said they will do RECURSIVE for 8.3, but there is no guarantee. Is there code for this yet? Who's the someone? :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Bundle of patches
Just a freshing for clean applying.. http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz Is any objections to commit? -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Bundle of patches
This is not responding to my concern. What you presented was an Sorry, I see your point now. Is that test enough? Or I should make more? -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: GNU TLS
* Martijn van Oosterhout (kleptog@svana.org) wrote: On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote: libjpeg, my other major open-source project, has always been shipped under a BSD-ish license that includes an advertising clause; I quote: : (2) If only executable code is distributed, then the accompanying : documentation must state that this software is based in part on the work of : the Independent JPEG Group. That's not an advertising clause, that merely asks that it be mentioned somewhere in the documentation, which is copied along with the rest of the code, so that's not limiting the redisitribution of anything. It also only applies when the source is not distributed, which means for the GPL it's a total non-issue. Exactly. There isn't a only executable code is distributed case when GPL code is involved so that clause wouldn't ever apply. Because there is a very large, very meaningful difference. Agreed. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Dead Space Map for vacuum
On Thu, 2006-12-28 at 21:35 +, Heikki Linnakangas wrote: I only used 1 bit, just like in Itagaki's approach. 1 bit may not be enough. In many cases, a block will receive only 1 UPDATE or DELETE. If we then mark this in the DSM, when we VACUUM that block it will not have sufficient space free to make it worth VACUUM adding the block to the FSM (using current thinking). That thinking is good, since tuples frequently vary in length, so we could easy be in a position that a block in the FSM doesn't even have space for a single new tuple version. I would suggest that we tracked whether a block has had 0, 1 or 1+ updates/deletes against it. When a block has 1+ it can then be worthwhile to VACUUM it and to place it onto the FSM. Two dead tuples is really the minimum space worth reclaiming on any block. Otherwise we will end up with a huge, not very useful FSM and fairly inefficient VACUUMing of single dead tuples. So I'd suggest that we used at least 2 bits/block, so that we can avoid fiddling with small amounts of reclaimed space. The extra space taken up by the DSM is easily outweighed by the space we would have wasted in the FSM to make it effective when tracking smaller chunks of freespace (which needs 6 bytes/block). DSM is a good thing; many use cases will benefit from it. I'd want to be able to turn off DSM completely when the whole database fits in RAM and would probably like to enable/disable it for particular tables, until we get some good heuristics for when it is worthwhile. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(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] TODO: GNU TLS
On Fri, Dec 29, 2006 at 08:31:34PM +1300, Mark Kirkwood wrote: [EMAIL PROTECTED] wrote: I will try again. It is a difficult subject for many. GPL software derived from PostgreSQL must honour the restrictions defined by the PostgreSQL (BSD) license. GPL software derived from OpenSSL must honour the restrictions defined by the OpenSSL license. What is the difference? Do you see it? You speak of compatibility as if it means that the above are different in some technical way. They are NOT different. Just because the GPL = the PostgreSQL license, does not allow you to disobey the PostgreSQL license restrictions. You *cannot* release your entire derived GPL product as GPL, if it is distributed with PostgreSQL. The PostgreSQL component retains the PostgreSQL licensing restrictions, The GPL restrictions do not supercede or replace the PostgreSQL component and there is NOTHING the GPL can do to change this. I think the issue revolves around the conditions that GPL stipulates about linking against libraries requiring the entire product to be *distributed* as GPL, even if components have differing licenses. This is the so-called viral clause that gets much attention! *nod* This is what people are thinking. It's about direction where the grey zone starts to occur. GPL is viral in that a GPL-derived product must be GPL. We're not talking about including GPL code in OpenSSL, though. This is about OpenSSL as the base library. The GPL cannot stipulate that a GPL program may only be linked against GPL libraries, or used on a GPL operating system, on GPL hardware. For example, if GNU coreutils is compiled for HP-UX. This is linking against software that is much more restrictive than the OpenSSL license. Is Stephen, or the people whose opinion he is repeating, going to claim that the FSF considers this an illegal distribution of GNU coreutils? The GPL can only require that any product *derived* from the work licensed with the GPL, only be derived from by products which are themselves GPL. I'm not that stunned that this is confusing to people. There is so much invalid information available, and most of us try to stay away from law as much as possible. It can be overwhelming. :-) Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much attention, but anyway, just trying to clarify why *in principle* that Stephen F is talking about a valid *possible* interpretation of the licensing maze... *nod* Thanks for the input. 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: GNU TLS
On Fri, Dec 29, 2006 at 09:52:08AM -0500, [EMAIL PROTECTED] wrote: I think the issue revolves around the conditions that GPL stipulates about linking against libraries requiring the entire product to be *distributed* as GPL, even if components have differing licenses. This is the so-called viral clause that gets much attention! We're not talking about including GPL code in OpenSSL, though. This is about OpenSSL as the base library. The GPL cannot stipulate that a GPL program may only be linked against GPL libraries, or used on a GPL operating system, on GPL hardware. For example, if GNU coreutils is compiled for HP-UX. This is linking against software that is much more restrictive than the OpenSSL license. Is Stephen, or the people whose opinion he is repeating, going to claim that the FSF considers this an illegal distribution of GNU coreutils? No, because that falls under the operating system exception. Additionally, linking against is no problem. It's *distributing* the linked against version that gets you in trouble. The GPL doesn't care about *use*, only about distribution. The GPL can only require that any product *derived* from the work licensed with the GPL, only be derived from by products which are themselves GPL. Correct. Additionally it can require that when you *distribute* that compiled GPL program (the compiled version being a derived work of the source), you provide the source to all the libraries used while running it (barring the operating system exception). It couldn't care less what licence is used by those libraries, as long as that licence is compatable with the requirements the GPL has of the source (which is not that the source must be GPL. I'm not that stunned that this is confusing to people. There is so much invalid information available, and most of us try to stay away from law as much as possible. It can be overwhelming. :-) The reason this issue is confusing is because it's nobodies fault. PostgreSQL by itself, no problem. Exim by itself, no problem. OpenSSL, by itself, no problem. It's only when Debian want's to *distribute* a compiled version of Exim linked against libpq while simultaneously complying with all the licences. Now Exim has granted an exception that gets Debian off the hook, but they didn't have to do that. Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much attention, but anyway, just trying to clarify why *in principle* that Stephen F is talking about a valid *possible* interpretation of the licensing maze... *nod* OpenSSL is a very different beast and one of very very few packages with this problem. See my other message. 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] [PATCHES] [BUGS] BUG #2846: inconsistent and
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: This is *not* going in the right direction :-( Well, then show me what direction you think is better. Fewer restrictions, not more. The thrust of what I've been saying (and I think Roman too) is to trust in the hardware float-arithmetic implementation to be right. Every time you add an additional error check you are going in the wrong direction. OK, are you saying that there is a signal we are ignoring for overflow/underflow, or that we should just silently overflow/underflow and not throw an error? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] WITH support
David Fetter wrote: On Thu, Dec 28, 2006 at 10:52:45PM -0500, Bruce Momjian wrote: Edwin Ramirez wrote: Hello, What is the status of supporting the WITH keyword? I see these TODO items: * Add SQL99 WITH clause to SELECT * Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT Are they the same item? Not exactly. There is a WITH in the SQL:2003 spec (T121 and T122) which doesn't include RECURSIVE, but they're related to the RECURSIVE one (T131). Someone has said they will do RECURSIVE for 8.3, but there is no guarantee. Is there code for this yet? Who's the someone? :) No code yet, and I don't remember who said they were working on it. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and
Bruce Momjian [EMAIL PROTECTED] writes: OK, are you saying that there is a signal we are ignoring for overflow/underflow, or that we should just silently overflow/underflow and not throw an error? Silent underflow is fine with me; it's the norm in most all float implementations and won't surprise anyone. For overflow I'm OK with either returning infinity or throwing an error --- but if an error, it should only be about inf-out-with-non-inf-in, not comparisons to any artificial MAX/MIN values. Anyone else have an opinion about this? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] TODO: GNU TLS
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
GPL software derived from PostgreSQL must honour the restrictions defined
by the PostgreSQL (BSD) license.
GPL software derived from OpenSSL must honour the restrictions defined
by the OpenSSL license.
You're talking about GPL software as if it's an entity to which licenses
can be granted and that's just not the case. Licenses are granted to
invidividuals and it's certainly possible that a license can say You
can distribute this code all you want, except if you put xyz on the same
CD as this code, because I don't like xyz. It's not at all uncommon
for licenses to be incompatible because when all is said and done all of
the licenses involved in a given applicaiton must be satisfied for the
application to be distributed.
In other words, to distribute exim4 the licenses of the following pieces
must all be satisfied:
exim4 itself (GPL)
libc6 (LGPL)
- tzdata ('public domain')
libdb4.3 (Kind of a BSD/GPL mix - Sleepycat, and newBSD for some parts)
libgnutls13 (LGPL)
- libgcrypt11 (LGPL, GPL for documentation)
- libgpg-error0 (LGPL)
- liblzo1 (GPL)
- libopencdk8 (GPL)
- libtasn1-3 (LGPL)
- zlib1g (BSDish)
libldap2 (BSDish - OpenLDAP, LGPL, BSDish - CRL, FSF Makefile.in,
BSDish - HC, BSDish - IBM, IS RFC license, BSDish - ISC, BSDish - JC,
BSDish - MA, BSDish - MIT, BSDish - PM, BSD w/ advertising clause from
UoC with a note that the advertising clause was retroactively removed
by UoC, BSD - UoC, BSDish - UoM with clarification from the OpenLDAP
foundation)
- libsasl2 (BSDish)
libmysqlclient15off (GPL)
- mysql-common (GPL)
libpam0g (BSDish)
- libpam-runtime (BSDish)
libpcre3 (BSDish or GPL if embedded with GPL software)
libperl5.8 (GPL or Artistic)
- perl-base (GPL or Artistic)
libpq4 (BSD)
- libcomerr2 (BSDish)
- libkrb53 (BSDish)
- libssl0.9.8 (BSD w/ advertising clause)
libsasl2-2 (BSDish)
- libdb4.4 (Kind of a BSD/GPL mix - Sleepycat, and newBSD for some
parts)
libsqlite3-0 ('public domain')
debconf (BSDish)
If any of these aren't satisfied then the resultant work can't be
distributed (that's the way copyright works, by default you have no
rights, at least here anyway, aiui).
What is the difference? Do you see it? You speak of compatibility as
if it means that the above are different in some technical way. They
are NOT different. Just because the GPL = the PostgreSQL license,
does not allow you to disobey the PostgreSQL license restrictions. You
I never said anything about obeying or disobeying the PostgreSQL
license.
*cannot* release your entire derived GPL product as GPL, if it is
distributed with PostgreSQL. The PostgreSQL component retains the
PostgreSQL licensing restrictions, The GPL restrictions do not
supercede or replace the PostgreSQL component and there is NOTHING the
GPL can do to change this.
An application can be released under more than one license. The GPL
understands this and doesn't say everything must be GPL!, it says that
those other licenses can't add any restrictions *beyond* those in the
GPL. The PostgreSQL license doesn't, so there isn't a problem with
combining Postgres (by itself) and GPL programs.
It's silliness. If you redistribute OpenSSL, you honour the OpenSSL
requirements. That's the *only* requirement by copyright law. It doesn't
matter if it is GPL on top, or not. You always honour each license.
The GPL says you can't combine GPL code with code which has additional
requirements and then distribute the result.
The GPL *cannot* say this. The GPL *cannot* define how OpenSSL can or
cannot be used. Only the OpenSSL license can define how OpenSSL is
allowed to be distributed or used once distributed.
Yeah, uh, licenses can say pretty much whatever they want and if you
don't follow them then you're not allowed to distribute it, that's the
way it works. The GPL doesn't define how OpenSSL can be distributed,
no, but what it *does* say (which it certainly can) is that you can't
distribute the *GPL* code when combined with the *OpenSSL* code, and
since the application is comprised of both you're SOL.
You are looking at it from the wrong direction. The GPL can prevent
*GPL-derived* works from being non-GPL. The GPL CANNOT prevent one
from deriving from non-GPL works. Take some time to read this a few
times if you need to. The difference is HUGE.
You're trying to make a distinction that the direction of the dependency
makes a difference. The problem is that there is no 'direction'. The
resulting application is built from both, and the resulting application
is what we're talking about. It doesn't matter that OpenSSL is lower or
higher on the call stack.
It would be ridiculous for it to be different. If it was different, it
would require all software to have exactly equivalent licenses in
order to be integrated. Insanity. Any lawyer who would claim this
should lose their license to practice law.
No, not equivalent, compatible, exactly
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: This is *not* going in the right direction :-( Well, then show me what direction you think is better. Fewer restrictions, not more. The thrust of what I've been saying (and I think Roman too) is to trust in the hardware float-arithmetic implementation to be right. Every time you add an additional error check you are going in the wrong direction. OK, are you saying that there is a signal we are ignoring for overflow/underflow, or that we should just silently overflow/underflow and not throw an error? My understanding is that you have to actually set flags in the floating point environment to make overflows, underflows, infinities, NaNs, etc. raise signals. You might take a look at fenv.h (defined in the C99 spec) for the functions to do this. My apologies if I'm recovering well trod ground here. Note that taking a signal on an FP exception is a horribly expensive proposition- we're talking about hundreds or thousands of clock cycles here. But it's probably worthwhile vr.s the cost of testing every floating point result, as generally FP exceptions will be rare (probably even more rare in database work than in general). So it's probably worthwhile. Brian
Re: [HACKERS] Dead Space Map for vacuum
Simon Riggs [EMAIL PROTECTED] writes: I would suggest that we tracked whether a block has had 0, 1 or 1+ updates/deletes against it. When a block has 1+ it can then be worthwhile to VACUUM it and to place it onto the FSM. Two dead tuples is really the minimum space worth reclaiming on any block. How do you arrive at that conclusion? Counterexample: table in which all tuples exceed half a page. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO: GNU TLS
* Martijn van Oosterhout (kleptog@svana.org) wrote: On Fri, Dec 29, 2006 at 09:52:08AM -0500, [EMAIL PROTECTED] wrote: We're not talking about including GPL code in OpenSSL, though. This is about OpenSSL as the base library. The GPL cannot stipulate that a GPL program may only be linked against GPL libraries, or used on a GPL operating system, on GPL hardware. For example, if GNU coreutils is compiled for HP-UX. This is linking against software that is much more restrictive than the OpenSSL license. Is Stephen, or the people whose opinion he is repeating, going to claim that the FSF considers this an illegal distribution of GNU coreutils? No, because that falls under the operating system exception. Additionally, linking against is no problem. It's *distributing* the linked against version that gets you in trouble. The GPL doesn't care about *use*, only about distribution. Right, if you actually distributed GNU coreutils *and* HP-UX together as an application, then, yes, that'd be a violation because of the additional restrictions put on the result by the HP-UX license. If you distributed GNU coreutils by itself but compiled to run on HP-UX systems then that's *not* a violation because the HP-UX code isn't being distributed as part of the application, even though it's linked against on the resultant system. The GPL can only require that any product *derived* from the work licensed with the GPL, only be derived from by products which are themselves GPL. Correct. Additionally it can require that when you *distribute* that compiled GPL program (the compiled version being a derived work of the source), you provide the source to all the libraries used while running it (barring the operating system exception). It couldn't care less what licence is used by those libraries, as long as that licence is compatable with the requirements the GPL has of the source (which is not that the source must be GPL. Right. I'm not that stunned that this is confusing to people. There is so much invalid information available, and most of us try to stay away from law as much as possible. It can be overwhelming. :-) The reason this issue is confusing is because it's nobodies fault. Yeah. :( Makes it more frustrating when trying to explain it to people too.. It's nothing you did, but... PostgreSQL by itself, no problem. Exim by itself, no problem. OpenSSL, by itself, no problem. It's only when Debian want's to *distribute* a compiled version of Exim linked against libpq while simultaneously complying with all the licences. (and then having libpq linked against OpenSSL) Now Exim has granted an exception that gets Debian off the hook, but they didn't have to do that. Right. If they didn't then it's conceivable that Exim could sue Debian for violating the GPL license. Not exactly likely to happen but being cautious it's best to get their explicit approval rather than playing the well, we'll just wait and see if they sue us game. Now as Tom pointed out, I dunno why OpenSSL suddenly gets so much attention, but anyway, just trying to clarify why *in principle* that Stephen F is talking about a valid *possible* interpretation of the licensing maze... *nod* OpenSSL is a very different beast and one of very very few packages with this problem. See my other message. Yup. Thankfully... It'd be quite the headache if there were alot of cases like this. :/ Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, are you saying that there is a signal we are ignoring for overflow/underflow, or that we should just silently overflow/underflow and not throw an error? Silent underflow is fine with me; it's the norm in most all float implementations and won't surprise anyone. For overflow I'm OK with either returning infinity or throwing an error --- but if an error, it should only be about inf-out-with-non-inf-in, not comparisons to any artificial MAX/MIN values. Anyone else have an opinion about this? If an underflow is not reported (And thus silently treated as zero), then it'd make sense for me to deal with overflows in a similar way, and just return infinity. The most correct solution would IMHO be to provide a guc variable strict_float_semantics that defaults to off, meaning that neather overflow nor underflow reports an error. If the variable was set to on, _both_ overflow and underflow would be reported. Just my €0.02 greetings, Florian Pflug ---(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
Martijn van Oosterhout kleptog@svana.org writes: On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote: libjpeg, my other major open-source project, has always been shipped under a BSD-ish license that includes an advertising clause; I quote: : (2) If only executable code is distributed, then the accompanying : documentation must state that this software is based in part on the work of : the Independent JPEG Group. That's not an advertising clause, That's not a fact, that's an opinion, and unless you're a lawyer who's studied the matter, I don't think your opinion carries much weight. Admittedly mine doesn't either --- but the point here is that it's extremely debatable whether there is any real difference between OpenSSL and other projects that no one is complaining about. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Recent SIGSEGV failures in buildfarm HEAD
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
here's a quick untested patch for buildfarm that Stefan might like to try.
Note that not all core files are named core. On some Linux distros,
it's configured to be core.PID by default.
And on some platforms, cores don't drop in the current working directory
... but until we have a problem that *only* manifests on such a
platform, I wouldn't worry about that. We do need to look for 'core*'
not just 'core', though.
That part is easy enough. And if people mangle their core location I am
certainly not going to go looking for it.
Don't forget the ulimit point either ... on most Linuxen there won't be
any core at all without twiddling ulimit.
Yeah. Perl actually doesn't have a core call for this. I have built some
code (see attached revised patch) to try to do it using a widespread but
non-standard module called BSD::Resource, but if the module is missing
it won't fail.
I'm actually wondering if unlimiting core might not be a useful switch
to provide on pg_ctl, as long as the platform has setrlimit().
cheers
andrew
--- run_build.pl.orig 2006-12-28 17:32:14.0 -0500
+++ run_build.pl.new2006-12-29 10:59:39.0 -0500
@@ -299,6 +299,20 @@
unlink $forcefile;
}
+# try to allow core files to be produced.
+# another way would be for the calling environment
+# to call ulimit. We do this in an eval so failure is
+# not fatal.
+eval
+{
+ require BSD::Resource;
+ BSD::Resource-import();
+ # explicit sub calls here using keeps compiler happy
+ my $coreok = setrlimit(RLIMIT_CORE,RLIM_INFINITY,RLIM_INFINITY);
+ die setrlimit unless $coreok;
+};
+warn failed to unlimit core size: $@ if $@;
+
# the time we take the snapshot
my $now=time;
my $installdir = $buildroot/$branch/inst;
@@ -795,6 +809,34 @@
$dbstarted=undef;
}
+
+sub get_stack_trace
+{
+ my $bindir = shift;
+ my $pgdata = shift;
+
+ # no core = no result
+ my @cores = glob($pgdata/core*);
+ return () unless @cores;
+
+ # no gdb = no result
+ system gdb --version /dev/null 21;
+ my $status = $? 8;
+ return () if $status;
+
+ my @trace;
+
+ foreach my $core (@cores)
+ {
+ my @onetrace = `gdb -ex bt --batch $bindir/postgres $core 21`;
+ push(@trace,
+ \n\n== stack trace: $core
==\n,
+@onetrace);
+ }
+
+ return @trace;
+}
+
sub make_install_check
{
my @checkout = `cd $pgsql/src/test/regress $make installcheck 21`;
@@ -814,6 +856,11 @@
}
close($handle);
}
+ if ($status)
+ {
+ my @trace =
get_stack_trace($installdir/bin,$installdir/data);
+ push(@checkout,@trace);
+ }
writelog('install-check',[EMAIL PROTECTED]);
print make installcheck log ===\n,@checkout
if ($verbose 1);
@@ -839,6 +886,11 @@
}
close($handle);
}
+ if ($status)
+ {
+ my @trace =
get_stack_trace($installdir/bin,$installdir/data);
+ push(@checkout,@trace);
+ }
writelog('contrib-install-check',[EMAIL PROTECTED]);
print make contrib installcheck log ===\n,@checkout
if ($verbose 1);
@@ -864,6 +916,11 @@
}
close($handle);
}
+ if ($status)
+ {
+ my @trace =
get_stack_trace($installdir/bin,$installdir/data);
+ push(@checkout,@trace);
+ }
writelog('pl-install-check',[EMAIL PROTECTED]);
print make pl installcheck log ===\n,@checkout
if ($verbose 1);
@@ -892,6 +949,13 @@
}
close($handle);
}
+ if ($status)
+ {
+ my @trace =
+
get_stack_trace($pgsql/src/test/regress/install$installdir/bin,
+
$pgsql/src/test/regress/tmp_check/data);
+ push(@makeout,@trace);
+ }
writelog('check',[EMAIL PROTECTED]);
print make check logs ===\n,@makeout
if ($verbose 1);
---(end of broadcast)---
TIP 6: explain analyze is your friend
[HACKERS] What's the difference between postgresql.conf.sample and postgresql.conf.sample.orig
I see the above-mentioned files in src/backend/utils/misc. A diff shows the following: $ diff postgresql.conf.sample.orig postgresql.conf.sample 223a224 log_destination = 'syslog' 302a304 silent_mode = on 363a366,367 autovacuum = on What's the purpose of postgresql.conf.sample.orig? I'm adding a GUC variable to submit a patch to allow tracing temp file usage. Do I need to add it to both? -- Bill Moran Collaborative Fusion Inc. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] What's the difference between postgresql.conf.sample
Bill Moran wrote: I see the above-mentioned files in src/backend/utils/misc. A diff shows the following: $ diff postgresql.conf.sample.orig postgresql.conf.sample 223a224 log_destination = 'syslog' 302a304 silent_mode = on 363a366,367 autovacuum = on What's the purpose of postgresql.conf.sample.orig? I'm adding a GUC variable to submit a patch to allow tracing temp file usage. Do I need to add it to both? My copy does not have any such file. Are you working on CVS HEAD? cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Recent SIGSEGV failures in buildfarm HEAD
Andrew Dunstan [EMAIL PROTECTED] writes: I'm actually wondering if unlimiting core might not be a useful switch to provide on pg_ctl, as long as the platform has setrlimit(). Not a bad thought; that's actually one of the reasons that I still usually use a handmade script rather than pg_ctl for launching postmasters ... regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] What's the difference between postgresql.conf.sample
In response to Andrew Dunstan [EMAIL PROTECTED]: Bill Moran wrote: I see the above-mentioned files in src/backend/utils/misc. A diff shows the following: $ diff postgresql.conf.sample.orig postgresql.conf.sample 223a224 log_destination = 'syslog' 302a304 silent_mode = on 363a366,367 autovacuum = on What's the purpose of postgresql.conf.sample.orig? I'm adding a GUC variable to submit a patch to allow tracing temp file usage. Do I need to add it to both? My copy does not have any such file. Are you working on CVS HEAD? Whups ... my mistake, the FreeBSD port includes a patch against postgresql.conf.sample, and the *.orig is the cruft left behind. Thanks for the quick reply. -- Bill Moran Collaborative Fusion Inc. ---(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's the difference between postgresql.conf.sample and postgresql.conf.sample.orig
Bill Moran [EMAIL PROTECTED] writes: What's the purpose of postgresql.conf.sample.orig? There is no such file in CVS ... perhaps it's left over from a patch run? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_restore fails with a custom backup file
On Tue, Dec 19, 2006 at 04:58:22PM +0100, Zeugswetter Andreas ADI SD wrote: MinGW has fseeko64 and ftello64 with off64_t. Maybe we need separate macros for MSVC and MinGW. Given the other You mean something quick and dirty like this ? That would work. Yes, except does that actually work? If so you found the place in the headers to stick it without breaking things that I couldn't find ;-) Compiles clean without warnings on MinGW, but not tested, sorry also no time. Does not compile on my MinGW - errors in the system headers (unistd.h, io.h) due to changing the argument format for chsize(). The change of off_t propagated into parts of the system headers, thus chaos was ensured. I still think we need to use a pgoff_t. Will look at combining these two approaches. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] TODO: GNU TLS
* Tom Lane ([EMAIL PROTECTED]) wrote: Martijn van Oosterhout kleptog@svana.org writes: On Fri, Dec 29, 2006 at 12:08:37AM -0500, Tom Lane wrote: libjpeg, my other major open-source project, has always been shipped under a BSD-ish license that includes an advertising clause; I quote: : (2) If only executable code is distributed, then the accompanying : documentation must state that this software is based in part on the work of : the Independent JPEG Group. That's not an advertising clause, That's not a fact, that's an opinion, and unless you're a lawyer who's studied the matter, I don't think your opinion carries much weight. It doesn't say All advertising materials ..., that makes it quite different from the OpenSSL clause. It also has the 'if only executable code is distributed' conditional, which the OpenSSL clause doesn't. Sure, I'm not a lawyer, but I'd have a hard time believing the two clauses so similar as to have the exact same effect with such differences. Admittedly mine doesn't either --- but the point here is that it's extremely debatable whether there is any real difference between OpenSSL and other projects that no one is complaining about. Each case is different and is considered seperately. I'm pretty sure that the libjpeg case has been considered and was found to not be a problem. While perhaps more cautious than most, Debian isn't actually out to make all the world GPL or to attempt to brow-beat everyone into following Stallman. We'd be perfectly happy for OpenSSL to just drop that clause but otherwise leave the license as BSDish, or even to change it to a clause such as that above (though if they can change the license at all, seems like it'd be best to just drop it, but whatever). Were that to happen we'd stop caring about using GNUTLS (at least, as a project). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and
Brian Hurt [EMAIL PROTECTED] writes: Note that taking a signal on an FP exception is a horribly expensive proposition- we're talking about hundreds or thousands of clock cycles here. But it's probably worthwhile vr.s the cost of testing every floating point result, as generally FP exceptions will be rare (probably even more rare in database work than in general). So it's probably worthwhile. I think we should probably stay away from relying on signals for this on portability grounds. The cost of checking the results is small, and will get smaller if we eliminate or simplify CheckFloat[48]Val as is being discussed here. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO: GNU TLS
Now Exim has granted an exception that gets Debian off the hook, but they didn't have to do that. Right. If they didn't then it's conceivable that Exim could sue Debian for violating the GPL license. Not exactly likely to happen but being cautious it's best to get their explicit approval rather than playing the well, we'll just wait and see if they sue us game. This is pure FUD, and unacceptable if spoken from a position of authority. State what you think this theoretical case would be. At least if you picked GPL including closed source code, you might be able to claim that the resulting derived work was not distributed complete with source code. OpenSSL, however, is open source. The only possible complaint could be you failed to advertise OpenSSL in the resulting distributed image, which would be a correct observation, easily corrected by the inclusion of a note in the documentation for the distributed software unit that includes both pieces of software. This correction is an existing requirement for any software distribution that includes OpenSSL, It is an acceptable, and easily honoured requirement. Anybody who has a problem admitting that their software distribution includes OpenSSL software in their documentation, has no sympathy from me. Attribution is an acceptable right to enforce under copyright law, and an honourable practice with or without a licensing requirement explicitly stating this as a requirement. Caution to the point of fantasy is a waste of resources. Caution to further a political agenda (not you - but the people whose opinions you are repeating) is exploitation. I am unable to find a single clause in the GPL (which I have analyzed many years ago, but also re-read several times in the last two days) that would make it impossible to satisfy all of the GPL, PostgreSQL (BSD) license, and the OpenSSL license at the same time. Every single clause of all three licenses can be easily satisfied without conflict. Those of you who are claiming otherwise, have failed to point to a single phrase in the GPL that could not be satisfied when distributing all three pieces of software as a single unit. Without a single point of true conflict between all three licenses, I do not accept that there is any case to require an OpenSSL exemption clause for Debian. Those who are doing so are doing a disservice to everyone by contributing to the general confusion on this subject. The clause is not required. The clause has no effect. To distribute a software unit that includes software from all of a GPL product, PostgreSQL, and OpenSSL, one needs only do the following: 1) Documentation for the software unit should include documentation to describe that the software includes OpenSSL. 2) The distribution of the software unit should include a text copy of all three licenses. 3) Source code for the entire unit should be provided. I don't believe the FSF can legally enforce this requirement, however, with GPL + PostgreSQL + OpenSSL, there is *NO* conflict. The source code for all three can be made available upon request, or contained within the distribution. 4) Various other minor points, such as the requirement that changes are dated and such. None of which conflict between the three licenses. To state again. There is *NO* conflict between the licenses. The terms of each can be fulfilled completely, and separately, without invalidating each other. Those who claim otherwise need to point to a specific requirement from one of the licenses that would prevent it from being used. They cannot, because such a point does not exist. Ascii pictures. Hearsay. Confusion regarding existing practice or existing thoughts on the matter. No single point of conflict has been raised. The GPL does not state that GPL software may not derive from software that has an advertising clause. Considering that this is the primary point raised by people, it is ironic that the GPL has no such restriction. Be honest about it. *You* don't like the advertising clause. The GPL has nothing to say on the issue, and therefore is *NOT* in conflict with it. This thread has re-enforced my conclusion that the GPL is a poor choice of license for any product I ever work on in the future. A decade ago, as a teenager, I thought it was cool to put GPL on the software that I made available to the world. I felt like I was part of something bigger. Now I just feel disgusted. The GPL is not about freedom. It is about enforcing a world view on all who use your software. Thank you PostgreSQL contributors for choosing the BSD style. I think it was an excellent choice. This is my last contribution to this thread. I've said my piece. Note that I don't intend to convert all of you. As this issue is primarily political, people will have a tendency to stay with their own camp, regardless of what is said. We all have a tendencies to read each others words, looking only for fault in
Re: [HACKERS] WITH Support
The WITH that I am thinking about, lets you define and reuse queries which are executed once. For example: WITH MySummary AS (*SELECT b.dept_name, Sum(Salary) AS total_sal FROM emp a join dept b on (a.dept_id = b.dept_id) GROUP BY b.dept_name*) SELECT dept_name, total_sal //FROM MySummary WHERE total_sal ( SELECT SUM (total_sal) * 1/12 FROM MySummary) ORDER BY total_sal You can introduce multiple aliases and use them within any subsequent queries. WITH alias1 as (...) alias2 as (...) alias3 as (...) SELECT Thanks, Edwin Ramirez wrote: Hello, What is the status of supporting the WITH keyword? I see these TODO items: * Add SQL99 WITH clause to SELECT * Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT Are they the same item? ---(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
On 12/29/06, Stephen Frost wrote: In the case above, exim4 *can* provide an exception because it's the *GPL* of *exim4* which is being violated by the advertising clause in the *OpenSSL* license. Which exim4 upstream has *done*, and which can be seen in their license (linked to previously in this thread). My question is whom is going to sue whom? And if so would they win? And if they win, will they win a crippling amount? Will the folks at exim sue? Not likely, they make free software that is DESIGNED to work with OpenSSL. Exim can be built to support encrypted SMTP connections... Before you can do this, you must install the OpenSSL library, which Exim uses for this purpose. Will they win if they sue? Not likely, there are probably lots of long legal terms (like latches, estoppal) that can be used in a defense. You can't go and build software specifically designed to use something, and over the course of years dupe people into using it only to go, ta-da, busted for additional GPL restrictions. And even if you succeed in this, you're not going to win big bucks. Perhaps you can simply prevent people from using your software. Given that using your software in the form you distribute it requires openssl, and you've sued people for using openssl with it, it's likely *no one* is going to use your software. And if you continue to dupe people into using your software and then suing them, you'd run some legal risks yourself. I mean, the theory of this legal case that debian people build seems terrible to me! Any case with this many highly unlikely AND clauses and such horrible outcomes for everyone seems unlikely to happen AND be won AND result in significant harm. If you don't like the advertising clause of openssl that is fine, avoid using software that uses it etc etc. But I think the debian hype of various forms of legal jeopardy goes a bit far, and does smell a bit FUDish. Fun to follow though. And if there is a nice implementation of GNUTLS that succeeds on the technical merits, no objection there either. - August ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] XML support in MSVC build
Magnus Hagander [EMAIL PROTECTED] writes: Attached patch adds support for the recent XML-in-backend stuff to the MSVC build. Most config stuff was already present for contrib/xml2, but needed to add the includes and defines to the backend build as well. Applied, thanks. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing
On 12/29/2006 12:23 AM, Bruce Momjian wrote:
Well, then show me what direction you think is better.
Think about this idea please. This has no INF, NaN or range
checks and detects all bad cases with any floating point
math.
The only issue is that a bad case is detected only once.
You need to restart the postmaster. It can be fixed by
re-enabling FP exceptions in the FP exception handler.
Roman
-
~/postgresql-8.2.0/src/backend/utils/adtdiff -U3 -p float.orig.c float.c
--- float.orig.c2006-12-29 10:49:51.0 -0600
+++ float.c 2006-12-29 10:58:19.0 -0600
@@ -60,12 +60,21 @@
#ifdef HAVE_IEEEFP_H
#include ieeefp.h
#endif
+#include fenv.h
#include catalog/pg_type.h
#include libpq/pqformat.h
#include utils/array.h
#include utils/builtins.h
+static void __attribute__((__constructor__))
+enable_fp_exceptions()
+{
+ feclearexcept(FE_ALL_EXCEPT);
+ feenableexcept(FE_DIVBYZERO | FE_UNDERFLOW | FE_OVERFLOW | FE_INVALID);
+ printf(FP exceptions enabled\n);
+}
+
#ifndef M_PI
/* from my RH5.2 gcc math.h file - thomas 2000-04-03 */
@@ -783,11 +792,10 @@ float4pl(PG_FUNCTION_ARGS)
{
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
- double result;
+ float4 result;
result = arg1 + arg2;
- CheckFloat4Val(result);
- PG_RETURN_FLOAT4((float4) result);
+ PG_RETURN_FLOAT4(result);
}
Datum
@@ -795,11 +803,10 @@ float4mi(PG_FUNCTION_ARGS)
{
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
- double result;
+ float4 result;
result = arg1 - arg2;
- CheckFloat4Val(result);
- PG_RETURN_FLOAT4((float4) result);
+ PG_RETURN_FLOAT4(result);
}
Datum
@@ -807,11 +814,10 @@ float4mul(PG_FUNCTION_ARGS)
{
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
- double result;
+ float4 result;
result = arg1 * arg2;
- CheckFloat4Val(result);
- PG_RETURN_FLOAT4((float4) result);
+ PG_RETURN_FLOAT4(result);
}
Datum
@@ -819,18 +825,10 @@ float4div(PG_FUNCTION_ARGS)
{
float4 arg1 = PG_GETARG_FLOAT4(0);
float4 arg2 = PG_GETARG_FLOAT4(1);
- double result;
-
- if (arg2 == 0.0)
- ereport(ERROR,
- (errcode(ERRCODE_DIVISION_BY_ZERO),
-errmsg(division by zero)));
-
- /* Do division in float8, then check for overflow */
- result = (float8) arg1 / (float8) arg2;
+ float4 result;
- CheckFloat4Val(result);
- PG_RETURN_FLOAT4((float4) result);
+ result = arg1 / arg2;
+ PG_RETURN_FLOAT4(result);
}
/*
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Recent SIGSEGV failures in buildfarm HEAD
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I'm actually wondering if unlimiting core might not be a useful switch to provide on pg_ctl, as long as the platform has setrlimit(). Not a bad thought; that's actually one of the reasons that I still usually use a handmade script rather than pg_ctl for launching postmasters ... this sounds like a good idea for me too - it seems like a cleaner and more useful thing on a general base then just doing it in the buildfarm code ... Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Deadline-Based Vacuum Delay
[EMAIL PROTECTED] (Jaime Casanova) writes: On 12/28/06, Tom Lane [EMAIL PROTECTED] wrote: Galy Lee [EMAIL PROTECTED] writes: So I am thinking another way to perform vacuum. For example vacuum can be refined in a maintenance time frame like VACUUM IN 6 HOURS, and then vacuum operation will be performed within the window. The delay time is adjusted internally to spread the disk I/O over the time frame. And you will manage that how? The total amount of work to be done is quite unpredictable. specially for something you already can do with cron (*nix) or job scheduler (windows) That seems like a nonsequitor here... Using cron to try to make vacuums spread over 6 hours seems to me like an attempt to try to do that in as terrible a way possible. If you're trying to spread work over time, you need to use something that actively monitors the results, as opposed to a tool that is entirely fire and forget (and perhaps forget to work), like cron. It seems to me that the answer is much more along the lines of making a greatly more intelligent autovacuum. Something offering: - Queueing work (e.g. - in this case, we want to schedule a vacuum of everything) - Processing that work; perhaps sometimes with multiple threads to do multiple vacuums - Perhaps using time estimates to determine any vacuum delay GUC values to be applied How you get the work to spread consistently across 6 hours is a challenge; personally, my preference would generally be to try to get the work done ASAP, so the goal seems a tad off to me... -- let name=cbbrowne and tld=linuxdatabases.info in String.concat @ [name;tld];; http://www3.sympatico.ca/cbbrowne/x.html The human race will decree from time to time: There is something at which it is absolutely forbidden to laugh. -- Nietzche on Common Lisp ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO: GNU TLS
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: Now Exim has granted an exception that gets Debian off the hook, but they didn't have to do that. Right. If they didn't then it's conceivable that Exim could sue Debian for violating the GPL license. Not exactly likely to happen but being cautious it's best to get their explicit approval rather than playing the well, we'll just wait and see if they sue us game. This is pure FUD, and unacceptable if spoken from a position of authority. State what you think this theoretical case would be. At I've made it clear previously, but sure, why not. The case would be something along the lines of Exim sueing Debian for building a derivative (Exim w/ OpenSSL) which violated the terms of distribution of Exim (GPL) which means Debian would be breaking copyright law by distributing the resulting application. With copyright law you have to show that you *have* the right, and anything which is done against the license which gives you that right which nullifies the license means you don't get to distribute the work, at all. There's really not a whole lot more to it than that, and there's nothing FUDdy about it. least if you picked GPL including closed source code, you might be able to claim that the resulting derived work was not distributed complete with source code. OpenSSL, however, is open source. The only The GPL requires more than just being 'open source'. possible complaint could be you failed to advertise OpenSSL in the resulting distributed image, which would be a correct observation, No, a complaint could be you didn't honor the terms of the GPL under which you received the rights to distribute the work. easily corrected by the inclusion of a note in the documentation for the distributed software unit that includes both pieces of software. This correction is an existing requirement for any software distribution that includes OpenSSL, It is an acceptable, and easily honoured requirement. Yet *having* that requirement on a *derived work* which includes GPL code is *against* the terms of the GPL. That's *exactly* the issue. The GPL says more than you must provide the source code to everything, it explicitly includes a requirement that no additional restrictions be put on the derivative (lest requirements for no-additional-distribution or must-charge-for-other-distribution be added which defeats much of the point of the GPL). Anybody who has a problem admitting that their software distribution includes OpenSSL software in their documentation, has no sympathy from me. Attribution is an acceptable right to enforce under copyright law, and an honourable practice with or without a licensing requirement explicitly stating this as a requirement. That's nice, it's got nothing to do with the conversation at hand, and might even be FUD based on how you've used that term previously. :) It's certainly rather frustrating to get these constant attacks during this conversation where you put up something I'm not advocating and then say only bad people would say such things! Caution to the point of fantasy is a waste of resources. Caution to further a political agenda (not you - but the people whose opinions you are repeating) is exploitation. I don't believe Debian has any kind of political agenda in this regard. Debian's agenda is to follow the licenses as best it can. While that may go beyond what others feel like doing it's a good goal to have. I am unable to find a single clause in the GPL (which I have analyzed many years ago, but also re-read several times in the last two days) that would make it impossible to satisfy all of the GPL, PostgreSQL (BSD) license, and the OpenSSL license at the same time. Every single clause of all three licenses can be easily satisfied without conflict. Those of you who are claiming otherwise, have failed to point to a single phrase in the GPL that could not be satisfied when distributing all three pieces of software as a single unit. Without a single point of true conflict between all three licenses, I do not accept that there is any case to require an OpenSSL exemption clause for Debian. Those who are doing so are doing a disservice to everyone by contributing to the general confusion on this subject. The clause is not required. The clause has no effect. Well, I pointed it out to you before but you seem to have happily ignored it so I'll provide it again here, perhaps more clearly: --- But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. --- --- 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject
Re: [HACKERS] TODO: GNU TLS
Caution to the point of fantasy is a waste of resources. Caution to further a political agenda (not you - but the people whose opinions you are repeating) is exploitation. I don't believe Debian has any kind of political agenda in this regard. Debian's agenda is to follow the licenses as best it can. While that may go beyond what others feel like doing it's a good goal to have. Actually everything about Debian (the project) is a political agenda. That doesn't mean that it is invalid though. That being said, this topic is WAY OFF-TOPIC for the discussion. The discussion is: Will we accept GNU TLS. Currently there has not been one technical argument that is valid to have us include GNU TLS. Now is their a legal argument? Maybe, but until an *attorney* states that there is an issue this is all m00t. Speaking of which I am going to bounce of to SPI and see if we can get an actual answer to this. Sincerely, Joshua D. Drake -- === 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 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] TODO: GNU TLS
* August Zajonc ([EMAIL PROTECTED]) wrote: On 12/29/06, Stephen Frost wrote: In the case above, exim4 *can* provide an exception because it's the *GPL* of *exim4* which is being violated by the advertising clause in the *OpenSSL* license. Which exim4 upstream has *done*, and which can be seen in their license (linked to previously in this thread). My question is whom is going to sue whom? And if so would they win? And if they win, will they win a crippling amount? Will the folks at exim sue? Not likely, they make free software that is DESIGNED to work with OpenSSL. I don't see that anyone is all that terribly *likely* to sue. Even so, it's best to follow the licenses under which we receive the rights to distribute the software as best we can. I can't say if they chose to sue if they'd win or not, I'd tend to doubt it based on such claims as those you describe but that doesn't mean I'm really all that anxious to actually find out for sure. Exim can be built to support encrypted SMTP connections... Before you can do this, you must install the OpenSSL library, which Exim uses for this purpose. Will they win if they sue? Not likely, there are probably lots of long legal terms (like latches, estoppal) that can be used in a defense. You can't go and build software specifically designed to use something, and over the course of years dupe people into using it only to go, ta-da, busted for additional GPL restrictions. No, Exim may have been a poor choice as an example, there's other GPL software which doesn't use OpenSSL directly but which does link against libpq. Even so though, our goal is to follow the licenses as best we can, not try to justify not following our understanding of the license based on the likelihood of a successful suit. And even if you succeed in this, you're not going to win big bucks. Perhaps you can simply prevent people from using your software. Given that using your software in the form you distribute it requires openssl, and you've sued people for using openssl with it, it's likely *no one* is going to use your software. And if you continue to dupe people into using your software and then suing them, you'd run some legal risks yourself. Unfortuantely, for many of us, just having to deal with a court at all implies a 'big bucks' cost. I mean, the theory of this legal case that debian people build seems terrible to me! Any case with this many highly unlikely AND clauses and such horrible outcomes for everyone seems unlikely to happen AND be won AND result in significant harm. If you don't like the advertising clause of openssl that is fine, avoid using software that uses it etc etc. But I think the debian hype of various forms of legal jeopardy goes a bit far, and does smell a bit FUDish. It'd only be jeopardy for Debian in any case... We'd just like to avoid the possibility by following the licenses as best we understand them. As for my personal feeling on the advertising clause, I'm not really a fan of it but at the same time it doesn't bother me all that much. We havn't got any choice if we want to use PostgreSQL w/ SSL though, do we? Fun to follow though. And if there is a nice implementation of GNUTLS that succeeds on the technical merits, no objection there either. As I posted about elsewhere, there are features in GNUTLS which aren't in OpenSSL, and vice-versa, along with claims of speed improvments from one over the other depending on platform. Also as mentioned last time this was brought up, GNUTLS is being used in quite a few different areas of Debian and has proven to work quite reasonably. (http://www.webservertalk.com/archive307-2006-4-1456230.html) Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Dead Space Map for vacuum
On Fri, 2006-12-29 at 10:49 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: I would suggest that we tracked whether a block has had 0, 1 or 1+ updates/deletes against it. When a block has 1+ it can then be worthwhile to VACUUM it and to place it onto the FSM. Two dead tuples is really the minimum space worth reclaiming on any block. How do you arrive at that conclusion? FSM code ignores any block with less space than 1 average tuple, which is a pretty reasonable rule. If you only track whether a block has been updated, not whether it has been updated twice, then you will be VACUUMing lots of blocks that have only a 50% chance of being usefully stored by the FSM. As I explained, the extra bit per block is easily regained from storing less FSM data. My understanding was that DSM was meant to increase VACUUM efficiency, so having a way to focus in on blocks most worth vacuuming makes sense using the 80/20 rule. Counterexample: table in which all tuples exceed half a page. Current FSM code will ignore those too, if they are less than the average size of the tuple so far requested. Thats a pretty wierd counterexample, even if it is a case that needs handling. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(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
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: Actually everything about Debian (the project) is a political agenda. That doesn't mean that it is invalid though. *smirk That being said, this topic is WAY OFF-TOPIC for the discussion. The discussion is: Will we accept GNU TLS. Currently there has not been one technical argument that is valid to have us include GNU TLS. Well, perhaps you weren't following everything but I did try to bring up a couple points about GNUTLS vs. OpenSSL which I'll mention again here where more people might actually notice it, heh: OpenSSL has more features and some niceties like the TLS_CACERTDIR (I've asked for this in GNUTLS, actually, so it might have it soon) They can each be faster than the other in some instances (I'm not sure which though, I've heard of 15% differences in each direction depending on architecture though) GNUTLS has a nicer/better API GNUTLS has a smaller memory footprint OpenSSL is working to get NIST certification/approval (it had it, but then lost it for some reason and they're working to get that fixed) GNUTLS has better documentation Actually, from a comparison done for libcurl (which supports both): GnuTLS vs OpenSSL While these two libraries offer similar features, they are not equal. Both libraries have features the other one lacks. libcurl does not (yet) offer a standardized stable ABI if you decide to switch from using libcurl-openssl to libcurl-gnutls or vice versa. The GnuTLS support is very recent in libcurl and it has not been tested nor used very extensively, while the OpenSSL equivalent code has been used and thus matured for more than seven (7) years. GnuTLS - LGPL licensened - supports SRP - lacks SSLv2 support - lacks MD2 support (used by at least some CA certs) - lacks the crypto functions libcurl uses for NTLM OpenSSL - Original BSD licensened - lacks SRP - supports SSLv2 - older and more widely used - provides crypto functions libcurl uses for NTLM - libcurl can do non-blocking connects with it in 7.15.4 and later That was from May 15, 2006: http://curl.mirrors.cyberservers.net/legal/distro-dilemma.html Regarding SSLv2 support, the GNUTLS page has this: Support for TLS 1.1, TLS 1.0 and SSL 3.0 protocols * Since SSL 2.0 is insecure it is not supported. * TLS 1.2 is supported in the experimental branch. Now is their a legal argument? Maybe, but until an *attorney* states that there is an issue this is all m00t. Speaking of which I am going to bounce of to SPI and see if we can get an actual answer to this. That would be interesting to find out. I'm kind of suprised it wasn't brought up before so that we could say well, from our understanding of what our lawyer said... or something along those lines. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] Bundle of patches
Teodor Sigaev [EMAIL PROTECTED] writes: Just a freshing for clean applying.. http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz Is any objections to commit? There's still a lot I don't particularly care for here (lack of documentation being the biggest), but I'll make a pass at cleaning it up. One thought I had after a quick reading of the patch is that there doesn't seem to be a whole lot of percentage in trying to move the typmod handling for time/timestamp/interval types into callable functions, because we still have to special-case the darn things thanks to the SQL spec's oddball syntax requirements. For instance in format_type_be() you've got case TIMETZOID: if (with_typemod) ! buf = psnprintf(50, time(%d) with time zone, ! typemod); else buf = pstrdup(time with time zone); break; changed to case TIMETZOID: if (with_typemod) ! buf = printTypmod(time, typemod, typeform-typmodoutput); else buf = pstrdup(time with time zone); break; which hardly seems like much of an improvement. If we could have gotten rid of the switch() branch for TIMETZOID entirely, then we'd be somewhere, but there's no chance because the typmod-less case still has to be special. So I'm sort of inclined to leave the processing of these datatypes as-is, and only use the typmodin/typmodout infrastructure for datatypes that follow the canonical syntax of type_name(int[,int ...]). Thoughts? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing
Roman Kononov [EMAIL PROTECTED] writes: Think about this idea please. This has no INF, NaN or range checks and detects all bad cases with any floating point math. Doesn't even compile here (no fenv.h). regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] TODO: GNU TLS
On Fri, Dec 29, 2006 at 10:32:34AM -0800, Joshua D. Drake wrote: Currently there has not been one technical argument that is valid to have us include GNU TLS. 1) The normal freedom that not being tied down to a single product provides. The same reason somebody might build MySQL + PostgreSQL support into their product. It usually forces a generic abstraction to be used, which may be a long term investment into a better code base within PostgreSQL. 2) Documentation is much better in GNUTLS. When using OpenSSL, I find myself frequently referring to the source code itself, as the best documentation available is for the now-possibly-out-of-date SSLeay. 3) Due to various political agendas, and legal confusion, GNUTLS has been steadily growing in popularity. One day it may be that GNUTLS is better maintained and well known than OpenSSL, at which point it might be a practical choice to only support GNUTLS, and drop support for OpenSSL entirely. 4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature state for a while. I don't understand why OpenSSL is still labelled as 0.9.x, which might indicate alpha quality, under heavy development. I don't find the reasons too compelling - but they are points to consider. 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: GNU TLS
entirely. 4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature state for a while. I don't understand why OpenSSL is still labelled as 0.9.x, which might indicate alpha quality, under heavy development. I don't find the reasons too compelling - but they are points to consider. 5) GNUTLS does not run well under all of our supported platforms. 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] [PATCHES] [BUGS] BUG #2846: inconsistent and confusing
On 12/29/2006 11:27 AM, Tom Lane wrote: Doesn't even compile here (no fenv.h). Where do you compile? Roman ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO: GNU TLS
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: 4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature state for a while. I don't understand why OpenSSL is still labelled as 0.9.x, which might indicate alpha quality, under heavy development. I don't find the reasons too compelling - but they are points to consider. 5) GNUTLS does not run well under all of our supported platforms. While I don't disagree about that, I would like to reiterate that I wouldn't advocate or even suggest dropping OpenSSL support or removing OpenSSL as the default. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Load distributed checkpoint
On Thu, Dec 28, 2006 at 09:28:48PM +, Heikki Linnakangas wrote: Tom Lane wrote: To my mind the problem with fsync is not that it gives us too little control but that it gives too much: we have to specify a particular order of writing out files. What we'd really like is a version of sync(2) that tells us when it's done but doesn't constrain the I/O scheduler's choices at all. Unfortunately there's no such API ... The problem I see with fsync is that it causes an immediate I/O storm as the OS tries to flush everything out as quickly as possible. But we're not in a hurry. What we'd need is a lazy fsync, that would tell the operating system let me know when all these dirty buffers are written to disk, but I'm not in a hurry, take your time. It wouldn't change the scheduling of the writes, just inform the caller when they're done. If we wanted more precise control of the flushing, we could use sync_file_range on Linux, but that's not portable. Nevertheless, I think it would be OK to have an ifdef and use it on platforms that support it, if it gave a benefit. I believe there's something similar for OS X as well. The question is: would it be better to do that, or to just delay calling fsync until the OS has had a chance to write things out. As a side note, with full_page_writes on, a checkpoint wouldn't actually need to fsync those pages that have been written to WAL after the checkpoint started. Doesn't make much difference in most cases, but we could take that into account if we start taking more control of the flushing. Hrm, interesting point, but I suspect the window involved there is too small to be worth worrying about. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Windows installer and dlls
Knut P. Lehre wrote: Installing postgresql 8.2.0 on Windows XP Pro SP2 using the msi installer dated 2006-12-04, with libeay32.dll and ssleay32.dll (both dated 2005-07-06) (and libiconv-2.dll, libintl-2.dll, and libpq.dll) from a previous installation (of version 8.0.5) already present in c:\windows\system32. These files in system32 did not appear to be updated during the 8.2.0 installation. Instead new files were placed in the postgresql bin directory: new versions of libeay32, ssleay32, and libpq, the same version as the present of libiconv-2 (2003-01-31), and, surprisingly, a libintl-2 with an older date (2003-02-01) than the file already present in system32 (2004-04-27). Is the libintl-2 supposed to be downgraded to a previous version? Not really :) Dave, can you comment on this? (it is correct that we don't *update* them, because we no longer touch these files in SYSTEM32) 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 ---(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] Dead Space Map for vacuum
Simon Riggs [EMAIL PROTECTED] writes: On Fri, 2006-12-29 at 10:49 -0500, Tom Lane wrote: Counterexample: table in which all tuples exceed half a page. Current FSM code will ignore those too, if they are less than the average size of the tuple so far requested. Thats a pretty wierd counterexample, even if it is a case that needs handling. Better read it again. The number that's passed to the FSM is the free space *after* vacuuming, which in this scenario will be BLCKSZ-less-page-header. This case is not broken now, but it will be if we adopt your proposal. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Load distributed checkpoint
Jim C. Nasby [EMAIL PROTECTED] writes: I believe there's something similar for OS X as well. The question is: would it be better to do that, or to just delay calling fsync until the OS has had a chance to write things out. A delay is not going to help unless you can suppress additional writes to the file, which I don't think you can unless there's very little going on in the database --- dirty buffers have to get written to make room for other pages, checkpoint in progress or no. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] effective_cache_size vs units
Benny Amorsen wrote: JCN == Jim C Nasby [EMAIL PROTECTED] writes: JCN Truth is, I bet many (if not most) DBAs barely know that case JCN matters in the units. Sounds like the school system needs fixing, then. Sure, but it probably shows a lot more prominently in other areas than in unit casing though. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Dead Space Map for vacuum
On Fri, 2006-12-29 at 16:41 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Fri, 2006-12-29 at 10:49 -0500, Tom Lane wrote: Counterexample: table in which all tuples exceed half a page. Current FSM code will ignore those too, if they are less than the average size of the tuple so far requested. Thats a pretty wierd counterexample, even if it is a case that needs handling. Better read it again. The number that's passed to the FSM is the free space *after* vacuuming, which in this scenario will be BLCKSZ-less-page-header. This case is not broken now, but it will be if we adopt your proposal. The case doesn't is extremely rare, since #define TOAST_TUPLE_THRESHOLD (MaxTupleSize / 4) Even so, I'm fairly certain that an if () statement is OK to handle that case. So I don't really understand that as a limit to the proposal, which is a small change in the scheme of things. DSM has my support; I would like it to be as efficient as possible. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Dead Space Map for vacuum
Simon Riggs wrote: On Fri, 2006-12-29 at 10:49 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: I would suggest that we tracked whether a block has had 0, 1 or 1+ updates/deletes against it. When a block has 1+ it can then be worthwhile to VACUUM it and to place it onto the FSM. Two dead tuples is really the minimum space worth reclaiming on any block. How do you arrive at that conclusion? FSM code ignores any block with less space than 1 average tuple, which is a pretty reasonable rule. FSM serves a different purpose than DSM and therefore has an entirely different set of rules governing what it should and shouldn't be doing. This is a reasonable rule for FSM, but not for DSM. If you only track whether a block has been updated, not whether it has been updated twice, then you will be VACUUMing lots of blocks that have only a 50% chance of being usefully stored by the FSM. As I explained, the extra bit per block is easily regained from storing less FSM data. Well, it seems that when implementing the DSM, it'd be a great time to move FSM from it's current location in Shared Memory to somewhere else. Possibly the same place as DSM. A couple of special blocks per file segment would a good place. Also I'm not sure that the point of VACUUMing is always to be able be able to immediately reuse the space. There are cases where large DELETE's are done, and you just want to decrease the index size. In Tom's counter example of large tuples, you certainly want to vacuum the index when only a single update/delete occurs. My understanding was that DSM was meant to increase VACUUM efficiency, so having a way to focus in on blocks most worth vacuuming makes sense using the 80/20 rule. Possibly true. I don't have anything to indicate what usage patterns produce what requirements in vacuum patterns. If there are significant numbers of blocks with one update, is it a loss to actually vacuum those. I know it could be faster if we didn't, but would it still be faster than what we do now. Counterexample: table in which all tuples exceed half a page. Current FSM code will ignore those too, if they are less than the average size of the tuple so far requested. Thats a pretty wierd counterexample, even if it is a case that needs handling. Again I'd be careful saying that FSM = DSM for handling of what should be done for a particular block. Russell Smith.
Re: [HACKERS] Dead Space Map for vacuum
On Sat, 2006-12-30 at 09:22 +1100, Russell Smith wrote: Simon Riggs wrote: FSM code ignores any block with less space than 1 average tuple, which is a pretty reasonable rule. FSM serves a different purpose than DSM and therefore has an entirely different set of rules governing what it should and shouldn't be doing. This is a reasonable rule for FSM, but not for DSM. VACUUM and space reuse are intimately connected. You cannot consider one without considering the other. If you only track whether a block has been updated, not whether it has been updated twice, then you will be VACUUMing lots of blocks that have only a 50% chance of being usefully stored by the FSM. As I explained, the extra bit per block is easily regained from storing less FSM data. Well, it seems that when implementing the DSM, it'd be a great time to move FSM from it's current location in Shared Memory to somewhere else. Possibly the same place as DSM. A couple of special blocks per file segment would a good place. Also I'm not sure that the point of VACUUMing is always to be able be able to immediately reuse the space. There are cases where large DELETE's are done, and you just want to decrease the index size. I can see the argument in favour of reducing index size, but do we want to perform a read *and* a write IO to remove *one* heap tuple, just so we can remove a single tuple from index(es)? We might want to eventually, but I'm proposing keeping track of that so that we can tell the difference between single dead tuples and more efficient targets for our VACUUM. When there are no better targets, sure, we'll be forced to reach for the high fruit. The idea of DSM is to improve the efficiency of VACUUM by removing wasted I/Os (and again I say, I back DSM). The zero-dead-tuples blocks are obvious targets to avoid, but avoiding them only avoids one read I/O. Avoiding the single-dead-tuple blocks avoids two I/Os, at small loss. They are poor targets for a selective VACUUM. When we are picking just some of the blocks in a table, we will quickly move from sequential to random I/O, so we must be careful and conservative about the blocks we pick, otherwise DSM VACUUM will not be any better than VACUUM as it is now. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Logging temp file useage ... a little advice would be appreciated
So I've got this patch (attached, against 8.2)
The goal is to track temp file usage as an aid to server tuning (such as
work_mem)
Most of the patch seems to work just dandy, except I'm getting weird
sizes reported:
2006-12-29 17:46:21 EST [45558]: [575-1] LOG: temp file: size 140737488343776
path base/32861/pgsql_tmp/pgsql_tmp45558.554
Seems a bit odd to have a 140T file on a 130G partition ...
I'm working on a FreeBSD 6.2 amd64 system. The headers show stat.st_size to
be of type off_t, which appears to be a 64-bit int. I figured that %ld
would be the correct format.
Am I hitting something such as file sparseness? Is this entire endeavour
doomed from the start? Or am I just making some sort of dumb mistake?
Any pointers are welcome.
--
Bill Moran
Collaborative Fusion Inc.
diff -r src.orig/backend/storage/file/fd.c src/backend/storage/file/fd.c
52a53
#include utils/guc.h
941c942,943
Vfd *vfdP;
---
Vfd *vfdP;
struct stat filestats;
970a973,981
if (fstat(vfdP-fd, filestats)) {
if (trace_temp_files)
ereport(LOG,
(errmsg(temp file: size %ld path \%s\,
filestats.st_size, vfdP-fileName)));
PG_TRACE1(temp__file__cleanup, filestats.st_size);
} else {
elog(ERROR, Could not stat \%s\: %m, vfdP-fileName);
}
diff -r src.orig/backend/utils/misc/guc.c src/backend/utils/misc/guc.c
183c183,184
---
bool trace_temp_files = false;
1013c1014,1024
---
{
{trace_temp_files, PGC_USERSET, LOGGING_WHAT,
gettext_noop(Enables logging the usage of temp files.),
gettext_noop(Size and location of each temp file is reported.),
NULL
},
trace_temp_files,
false, NULL, NULL
},
1474c1485
---
diff -r src.orig/backend/utils/misc/postgresql.conf.sample src/backend/utils/misc/postgresql.conf.sample
335a336
#trace_temp_files = off # Log usage of temporary files
diff -r src.orig/include/utils/guc.h src/include/utils/guc.h
125a126
extern bool trace_temp_files;
---(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
On Friday 29 December 2006 14:49, Joshua D. Drake wrote:
entirely.
4) GNUTLS development seems more active? OpenSSL has been in a
frozen/mature state for a while. I don't understand why OpenSSL is still
labelled as 0.9.x, which might indicate alpha quality, under heavy
development.
I don't find the reasons too compelling - but they are points to
consider.
5) GNUTLS does not run well under all of our supported platforms.
given options like --enable-dtrace and --with-libedit-preferred, I don't find
this argument compelling...
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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
On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote: On Friday 29 December 2006 14:49, Joshua D. Drake wrote: entirely. 4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature state for a while. I don't understand why OpenSSL is still labelled as 0.9.x, which might indicate alpha quality, under heavy development. I don't find the reasons too compelling - but they are points to consider. 5) GNUTLS does not run well under all of our supported platforms. given options like --enable-dtrace and --with-libedit-preferred, I don't find this argument compelling... I don't like either of those options either. Joshua D. Drake -- === 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 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] Deadline-Based Vacuum Delay
On 12/29/06, Chris Browne [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Jaime Casanova) writes: On 12/28/06, Tom Lane [EMAIL PROTECTED] wrote: Galy Lee [EMAIL PROTECTED] writes: So I am thinking another way to perform vacuum. For example vacuum can be refined in a maintenance time frame like VACUUM IN 6 HOURS, and then vacuum operation will be performed within the window. The delay time is adjusted internally to spread the disk I/O over the time frame. And you will manage that how? The total amount of work to be done is quite unpredictable. specially for something you already can do with cron (*nix) or job scheduler (windows) That seems like a nonsequitor here... Using cron to try to make vacuums spread over 6 hours seems to me like an attempt to try to do that in as terrible a way possible. that's entirely my point... what th op was proposing was a command VACUUM IN n HOURS... he want to write the command... he didn't talk about a tool for monitoring jus a tool that he fire and forget... at least that was the way a read it... -- 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] Logging temp file useage ... a little advice wouldbe appreciated
On Fri, 2006-12-29 at 17:53 -0500, Bill Moran wrote: So I've got this patch (attached, against 8.2) The goal is to track temp file usage as an aid to server tuning (such as work_mem) Most of the patch seems to work just dandy, except I'm getting weird sizes reported: 2006-12-29 17:46:21 EST [45558]: [575-1] LOG: temp file: size 140737488343776 path base/32861/pgsql_tmp/pgsql_tmp45558.554 Seems a bit odd to have a 140T file on a 130G partition ... The fd can be set to VFD_CLOSED just above where you've patched. Try stat-ing the filename instead, as the unlink does. Your patches should be diff -c format, submitted to -patches, please. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] psql possible TODO
Tom Lane wrote: Richard Troy [EMAIL PROTECTED] writes: ... it occurs to me that perhaps Josh can implement a command line switch to turn on command line numbering. That would solve the problem I have with changing \s. I think a psql \set variable (comparable to ON_ERROR_STOP and friends) might be the way to go instead of inventing another \-command, but it's not real important. So, is anybody working on this? I think it should be put in the TODO list: - Allow psql to display item numbers along each history item, depending on a \set variable -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(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] TODO: GNU TLS
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote: On Friday 29 December 2006 14:49, Joshua D. Drake wrote: given options like --enable-dtrace and --with-libedit-preferred, I don't find this argument compelling... I don't like either of those options either. What about --with-pam, --with-ldap, --with-gnu-ld ? I also wonder about --with-tcl, --with-perl, --with-python, --with-krb5.. We do support quite a few platforms... Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] TODO: GNU TLS
On Fri, 2006-12-29 at 18:56 -0500, Stephen Frost wrote: * Joshua D. Drake ([EMAIL PROTECTED]) wrote: On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote: On Friday 29 December 2006 14:49, Joshua D. Drake wrote: given options like --enable-dtrace and --with-libedit-preferred, I don't find this argument compelling... I don't like either of those options either. What about --with-pam, --with-ldap, --with-gnu-ld ? I also wonder about --with-tcl, --with-perl, --with-python, --with-krb5.. We do support quite a few platforms... I do not like --enable-dtrace because it is a Solaris only thing and a waste of maintability resources (although small). I do not like --with-libedit-preferred because I think it should be --with-libedit and readline should be ripped out. I do not like --with-krb5 because it has extremely limited real world use. I do not like --with-tcl because well... it is tcl I do not like --with-pam but only because I have never gotten it to work. I do like --with-python because all other languages are inferior. I do like --with-ldap because it is pretty much standard within directory lookups by the nature of Active Directory. I do not like Green Eggs and Ham, said Sam I am. Sincerely, Joshua D. Drake Thanks, Stephen -- === 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 6: explain analyze is your friend
Re: [HACKERS] TODO: GNU TLS
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: I do not like --enable-dtrace because it is a Solaris only thing and a waste of maintability resources (although small). While the analysis can only be done on Solaris I feel that improvments from the analysis may be useful on other platforms. For that I don't feel it's a waste of resources. I do not like --with-libedit-preferred because I think it should be --with-libedit and readline should be ripped out. Not all that particular on this one as long as my psql works well. :) I do like the improvments in 8.2 too. I do not like --with-krb5 because it has extremely limited real world use. Riiigghhhttt... Only every Windows setup which uses Active Directory, most major universities, and certain large corporations (uh, AOL?) would even think to use something like Kerberos! I do not like --with-tcl because well... it is tcl Haha. I do not like --with-pam but only because I have never gotten it to work. We use it on some of our production systems (since it can provide cracklib, password expiration, etc, and the postgres instance inside it's own vserver so it doesn't hurt as much to make the passwd/shadow files available to it...). I'd be happy to help you get it to work if you'd like, and I could even provide you with some PG/C functions to use password changing and password aging. :) I do like --with-python because all other languages are inferior. haha. I do like --with-ldap because it is pretty much standard within directory lookups by the nature of Active Directory. Funny you like LDAP but not Kerberos, both of which are part of Active Directory... Using LDAP simple binds to AD for authentication is *quite* silly and *much* less secure than using Kerberos... I do not like Green Eggs and Ham, said Sam I am. hehe. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] TODO: GNU TLS
I do not like --with-krb5 because it has extremely limited real world use. Riiigghhhttt... Only every Windows setup which uses Active Directory, most major universities, and certain large corporations (uh, AOL?) would even think to use something like Kerberos! I said Extremely Limited real world use. Between just two of my customers, in the next 2 years we (CMD) will have 12 thousand postgresql installations. Not one of them will use Kerberos. I do not like --with-pam but only because I have never gotten it to work. We use it on some of our production systems (since it can provide cracklib, password expiration, etc, and the postgres instance inside it's own vserver so it doesn't hurt as much to make the passwd/shadow files available to it...). I'd be happy to help you get it to work if you'd like, and I could even provide you with some PG/C functions to use password changing and password aging. :) Oh, I am sure it is great. I have just never tried that hard to get it to work :) I do like --with-ldap because it is pretty much standard within directory lookups by the nature of Active Directory. Funny you like LDAP but not Kerberos, both of which are part of Active Directory... Using LDAP simple binds to AD for authentication is *quite* silly and *much* less secure than using Kerberos... Yes but LDAP gives me a lot of other things, easily and it has SSL. SSL + Firewall gives me 98% of the security I need. Sincerely, Joshua D. Drake -- === 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 6: explain analyze is your friend
Re: [HACKERS] TODO: GNU TLS
On Dec 29, 2006, at 7:09 PM, Joshua D. Drake wrote: On Fri, 2006-12-29 at 18:56 -0500, Stephen Frost wrote: * Joshua D. Drake ([EMAIL PROTECTED]) wrote: On Fri, 2006-12-29 at 17:57 -0500, Robert Treat wrote: On Friday 29 December 2006 14:49, Joshua D. Drake wrote: given options like --enable-dtrace and --with-libedit-preferred, I don't find this argument compelling... I don't like either of those options either. What about --with-pam, --with-ldap, --with-gnu-ld ? I also wonder about --with-tcl, --with-perl, --with-python, --with-krb5.. We do support quite a few platforms... I do not like --enable-dtrace because it is a Solaris only thing and a waste of maintability resources (although small). It works on solaris, opensolaris, all the distributions based on opensolaris. It should work in the next version of Mac OS X and most likely in the next version of FreeBSD. The dtrace allows people to answer questions on production systems that were otherwise mysteries. I think it is not a waste at all. I do not like --with-libedit-preferred because I think it should be --with-libedit and readline should be ripped out. I do not like --with-krb5 because it has extremely limited real world use. I see quite a bit of kerberos in the Enterprise world. I do not like --with-tcl because well... it is tcl I do not like --with-pam but only because I have never gotten it to work. I do like --with-python because all other languages are inferior. I do like --with-ldap because it is pretty much standard within directory lookups by the nature of Active Directory. I do not like Green Eggs and Ham, said Sam I am. I don't understand why this has devolved into an argument about what people do and don't like. It's like specifically choosing a forum that will have the most disagreement. // Theo Schlossnagle // CTO -- http://www.omniti.com/~jesus/ // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ ---(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
I don't understand why this has devolved into an argument about what people do and don't like. It's like specifically choosing a forum that will have the most disagreement. Yep :), I saw we go over to debian-general and ask why they are trying to make all these projects use GNU/TLS ;) Joshua D. Drake // Theo Schlossnagle // CTO -- http://www.omniti.com/~jesus/ // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ ---(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 -- === 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO: GNU TLS
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: I do not like --with-krb5 because it has extremely limited real world use. Riiigghhhttt... Only every Windows setup which uses Active Directory, most major universities, and certain large corporations (uh, AOL?) would even think to use something like Kerberos! I said Extremely Limited real world use. Between just two of my customers, in the next 2 years we (CMD) will have 12 thousand postgresql installations. Not one of them will use Kerberos. There's no accounting for poor taste... I do not like --with-pam but only because I have never gotten it to work. We use it on some of our production systems (since it can provide cracklib, password expiration, etc, and the postgres instance inside it's own vserver so it doesn't hurt as much to make the passwd/shadow files available to it...). I'd be happy to help you get it to work if you'd like, and I could even provide you with some PG/C functions to use password changing and password aging. :) Oh, I am sure it is great. I have just never tried that hard to get it to work :) Oh, I never said it was great, just said that we used it since PG doesn't directly provide the things we need (cracklib, password aging, etc). I do like --with-ldap because it is pretty much standard within directory lookups by the nature of Active Directory. Funny you like LDAP but not Kerberos, both of which are part of Active Directory... Using LDAP simple binds to AD for authentication is *quite* silly and *much* less secure than using Kerberos... Yes but LDAP gives me a lot of other things, easily and it has SSL. SSL + Firewall gives me 98% of the security I need. Unfortunately, security isn't a game of percentages. Hopefully you'll never have a server compromised which is then used to capture passwords which can then be used to jump to other systems... Kerberos is there and it's not too hard to use (though does depend on the MIT Kerberos for Windows service currently). Supporting SSPI/GSSAPI and then writing a small document on how to generate Windows keytabs for Postgres would mean single-sign-on for Windows users using applications which use libpq... Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] psql possible TODO
Alvaro Herrera wrote: Tom Lane wrote: Richard Troy [EMAIL PROTECTED] writes: ... it occurs to me that perhaps Josh can implement a command line switch to turn on command line numbering. That would solve the problem I have with changing \s. I think a psql \set variable (comparable to ON_ERROR_STOP and friends) might be the way to go instead of inventing another \-command, but it's not real important. So, is anybody working on this? I think it should be put in the TODO list: - Allow psql to display item numbers along each history item, depending on a \set variable I thought Joshua Drake was going to submit a patch, but if doesn't appear shortly, I will add it to the TODO list with the agreed API. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Load distributed checkpoint
Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: I believe there's something similar for OS X as well. The question is: would it be better to do that, or to just delay calling fsync until the OS has had a chance to write things out. A delay is not going to help unless you can suppress additional writes to the file, which I don't think you can unless there's very little going on in the database --- dirty buffers have to get written to make room for other pages, checkpoint in progress or no. I am afraid a delay between write and fsync is the only portable option we have right now --- there is hope that since the check point write, we will not have a huge number of dirty buffers at the start of the checkpoint that need to be written out. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] psql possible TODO
On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote: Alvaro Herrera wrote: Tom Lane wrote: Richard Troy [EMAIL PROTECTED] writes: ... it occurs to me that perhaps Josh can implement a command line switch to turn on command line numbering. That would solve the problem I have with changing \s. I think a psql \set variable (comparable to ON_ERROR_STOP and friends) might be the way to go instead of inventing another \-command, but it's not real important. So, is anybody working on this? I think it should be put in the TODO list: - Allow psql to display item numbers along each history item, depending on a \set variable I thought Joshua Drake was going to submit a patch, but if doesn't appear shortly, I will add it to the TODO list with the agreed API. I will claim this for now. I will let it go if I can't get at least something productive done on it by end of January. Joshua D. Drake -- === 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Load distributed checkpoint
On Fri, Dec 29, 2006 at 09:02:11PM -0500, Bruce Momjian wrote: Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: I believe there's something similar for OS X as well. The question is: would it be better to do that, or to just delay calling fsync until the OS has had a chance to write things out. A delay is not going to help unless you can suppress additional writes to the file, which I don't think you can unless there's very little going on in the database --- dirty buffers have to get written to make room for other pages, checkpoint in progress or no. I am afraid a delay between write and fsync is the only portable option we have right now --- there is hope that since the check point write, we will not have a huge number of dirty buffers at the start of the checkpoint that need to be written out. We could potentially control that behavior, too. For example, trying to suppress writes to a given file when we're getting ready to checkpoint it (of course, separating checkpointing into a file-by-file operation is a non-trivial change, but it should be possible). -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] TODO: GNU TLS
Robert Treat wrote: On Friday 29 December 2006 14:49, Joshua D. Drake wrote: entirely. 4) GNUTLS development seems more active? OpenSSL has been in a frozen/mature state for a while. I don't understand why OpenSSL is still labelled as 0.9.x, which might indicate alpha quality, under heavy development. I don't find the reasons too compelling - but they are points to consider. 5) GNUTLS does not run well under all of our supported platforms. given options like --enable-dtrace and --with-libedit-preferred, I don't find this argument compelling... Keep in mind it took years to get OpenSSL support up to the level we have it now. It took SSL experts coming in and out of our development process to get it 100% feature-complete. Doing this for another library, I am afraid, isn't trivial, unlike the above options. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] TODO: GNU TLS
Bruce Momjian wrote: Robert Treat wrote: 5) GNUTLS does not run well under all of our supported platforms. given options like --enable-dtrace and --with-libedit-preferred, I don't find this argument compelling... Keep in mind it took years to get OpenSSL support up to the level we have it now. It took SSL experts coming in and out of our development process to get it 100% feature-complete. Doing this for another library, I am afraid, isn't trivial, unlike the above options. Not only that, but in every other case of an extra library, it provides us either with more platform support (e.g. libedit) or more functionality (e.g. dtrace). That's not the case here - we would simply be supporting another way of getting the same functionality on platforms where we already have a library that supports it. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: column ordering, was Re: [HACKERS] [PATCHES] Enums patch v2
On Thu, Dec 21, 2006 at 11:43:27AM -0500, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: You could make a case that we need *three* numbers: a permanent column ID, a display position, and a storage position. Could this not be handled by some catalog fixup after an add/drop? If we get the having 3 numbers you will almost have me convinced that this might be too complicated after all. Actually, the more I think about it the more I think that 3 numbers might be the answer. 99% of the code would use only the permanent ID. Display position would be used in *exactly* one place, namely while expanding SELECT foo.* --- I can't think of any other part of the backend that would care about it. (Obviously, client-side code such as psql's \d would use it too.) Use of storage position could be localized into a few low-level tuple access functions, probably. The problems we've been having with the concept stem precisely from trying to misuse either display or storage position as a permanent ID. That's fine as long as it actually is permanent, but as soon as you want to change it then you have problems. We should all understand this perfectly well from a database theory standpoint: pg_attribute has to have a persistent primary key. (attrelid, attnum) is that key, and we can't go around altering a column's attnum without creating problems for ourselves. Is there enough consensus on this to add it to the TODO? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] WITH support
On 12/29/06, Bruce Momjian [EMAIL PROTECTED] wrote: No code yet, and I don't remember who said they were working on it. I'm still waiting to hear from Mark Cave-Ayland on whether he's going to pick it up or whether I'll just do it. One way or another, there should be some movement regarding design discussion within a week or two. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(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] Deadline-Based Vacuum Delay
Chris Browne [EMAIL PROTECTED] writes: How you get the work to spread consistently across 6 hours is a challenge; personally, my preference would generally be to try to get the work done ASAP, so the goal seems a tad off to me... I think the context for this is that you have an agreed-on maintenance window, say extending from 2AM to 6AM local time, and you want to get all your vacuuming done in that window without undue spikes in the system load (because you do still have live users then, just not as many as during prime time). If there were a decent way to estimate the amount of work to be done then it'd be possible to spread the work fairly evenly across the window. What I do not see is where you get that estimate from --- especially since you probably have more than one table to vacuum in your window. The other problem is that vacuum only during a maintenance window doesn't seem all that compelling a policy anyway. We see a lot of examples of tables that need to be vacuumed much more often than once a day. So I'd rather put effort into making sure that vacuum can be run in the background even under high load, instead of designing around a maintenance-window assumption. 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] TODO: GNU TLS
Bruce Momjian [EMAIL PROTECTED] writes: Keep in mind it took years to get OpenSSL support up to the level we have it now. It took SSL experts coming in and out of our development process to get it 100% feature-complete. Actually, it's *not* feature-complete even yet. What basically bothers me about this is that trying to support both the OpenSSL and GNUTLS APIs is going to be an enormous investment of development and maintenance effort, because it's such a nontrivial thing to use properly. It sticks in my craw to be doing that work for no technical reason, only a license-lawyering reason; and not even a license issue that everyone is convinced is real. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
