Re: [GENERAL] responses to licensing discussion
Hi Postgresql Colleagues, I have been a user of Postgresql for a long time and seldom post here, but after reading the recent fray over license changes, I feel compelled to post this. Just to add my miniscule .02 to this discussion As a contributor to open source (and also a commercial developer) for many years, I lament the fact that lawyers of whatever stripe now seek to both advise and capitalize on the creativity and generosity of the worldwide technical community who contribute freely to develop and make available programs like Postgresql. What a pity! We (at least in the US) live in such a litigious society (nearly everyone seems unwilling to take responsibility for their own actions) that we now need legal advice and opinions on how to protect individuals who give freely of their own time and creativity. I guess this is why people (and even medical professionals) in the US will seldom stop to help someone who is in need anymore. (they might get sued for doing a good deed!!!) If you are employed by someone like M$ your corporate profits can afford these high priced prostitutes to keep you safe from law suits by people and organizations too ignorant to know what they are doing and who are unwilling to accept responsibility for their own actions. However, if you are an open source contributor and are intelligent and creative and contributing to something worthwhile to humanity for zero personal gain... (such as developing code that overall benefits society), you must still consort with these vultures for fear you may lose your livelihood to one of the people you sought to help. Call me naieve, idealistic, stupid, unrealistic or whatever... but I find the whole discussion simply an amazing (and also deplorable) commentary on the current state of affairs. BTW...are the people who write the VB (aka virus builder) programs such as the recent "love bug" covered under UCITA?? Perhaps this would be a good new business venture for the lawyers? I think I remember hearing some FBI people lamenting the fact that Phillipine law would not permit prosecution. Maybe we can get them covered under Virginia law also! After all, these people did slightly more damage in one day than all the bugs in the history of open source programs like Postgresql. Along the same lines...is MicroSoft liable for having released VBA? I have not seen any lawsuits aimed at Bill and the VBA developers for having provided such easily abusable "functionality" in their product? Sorry for the rant... Regards, Jim ,-,-. ,-,-. ,-,-. ,-,-. ,- / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / / `-'-' `-'-' `-'-' `-'-' FSC - Building Better Information Technology Solutions- From the Production Floor to the Customer's Door. Jim Jennis, Technical Director, Commercial Systems Fuentez Systems Concepts, Inc. 1 Discovery Place, Suite 2 Martinsburg, WV. 25401 USA. Phone: +001 (304) 263-0163 ext 235 FAX: +001 (304) 263-0702 Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Web: http://www.discovery.fuentez.com/ ---
Re: [GENERAL] Question about tape backup of online database.
"Robert B. Easter" wrote: > > I'd like to know what hardware and software people use to perform tape backup > of an online database on Linux. I would imagine the following might work(?): > > 1. Use RAID mirroring of the disk the db is on onto 2 two or more other > disks. > 2. When it is time to do the backup, disconnect one of the disks from the > mirror and then dump the whole disk partition to a tape(s). That won't do unless you take the database down for the disconnect - a live database's file image may not be consistent over a backup. pg_dump is the only supplied way to dump a live database. > 3. Reconnect the disk back to the mirror and let it begin rebuilding. > > Right now, I don't even have SCSI! If you can tell me your setup and > backup procedure, I'd be grateful. If you do not want to take the database offline or save to a temporary file, I'd suggest something like "mt rewind ; pg_dump -o -z > /dev/tape". There is a new pg_dump/pg_restore out in beta now as pg_backupXXX_latest on the PostgreSQL site which appears to be neater than the dumper supplied in the PostgreSQL tarball. Sevo -- Sevo Stille [EMAIL PROTECTED]
Re: [GENERAL] Re: Anyone using ReiserFS in production work? (oradvise against it?)
On Tue, 4 Jul 2000 [EMAIL PROTECTED] wrote: > "Randall Parker" <[EMAIL PROTECTED]> writes: > > > The title says it all: Is this a foolhardy or prudent and wise move > > at this time? > > > > Has anyone run Postgres databases on ReiserFS volumes under heavy > > enough load and for long enough to get a sense of how stable it is? Not very heavy load, but for long enough time. > > Anyone tried pulling the power plug under heavy load to find out if > > ReiserFS is less prone to volume corruption than ext2 under these > > circumstances? Less. I never had "bad" corruption with reiser. On other hand, I never had 'bad' corruption with ext2 either. ;) But theoretically, its possible with ext2 and avoidable with reiser.
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
[EMAIL PROTECTED] (Jan Wieck) writes: > Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: > > [EMAIL PROTECTED] (Jan Wieck) writes: > > > > > Trond Eivind Glomsrød wrote: > > > > [EMAIL PROTECTED] (Jan Wieck) writes: > > > > > > > > > Trond Eivind Glomsrød wrote: > > > > > > Mike Mascari <[EMAIL PROTECTED]> writes: > > > > > > > > > > > > > This is not something new. SunOS, AIX, HPUX, etc. all have (at > > > > > > > one time or another) considerable BSD roots. And yet FreeBSD > > > > > > > still exists... All GPL does is 'poison' the pot by prohibiting > > > > > > > commercial spawns which may leverage the code. > > > > > > > > > > > > GPL doesn't prohibit commercial spawns - it just requires you to send > > > > > > the source along. > > > > > > > > > > So if someone offers $$$ for implementation of Postgres > > > > > feature XYZ I don't have to make that code open source? > > > > > > > > You don't have to tell the world they can have it for free - you can > > > > sell it, and develop it by demand. > > > > > > > > > Only need to ship the code to the one paying > > > > > > > > Yes. > > > > > > Now I don't want to ship the source code. My customer would > > > be happy with a patched 8.2.3 binary as long as I'm > > > responsible to patch future versions until I release the > > > sources. Is that OK? > > > > You don't have to give the customer the source, as long as you > > gurantee that he gets it (for cost of distribution) if he wants it. > > Wordy, but how can I prevent him to ask for? By doing everything he wants (and perfect) so he doesn't have a need for it? Basically, GPL is intended to protect the end user and guaranteeing him the source if he wants it - and that he can do what he wants to with it, as long as he doesn't prevent others from doing so. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: > [EMAIL PROTECTED] (Jan Wieck) writes: > > > Trond Eivind Glomsrød wrote: > > > [EMAIL PROTECTED] (Jan Wieck) writes: > > > > > > > Trond Eivind Glomsrød wrote: > > > > > Mike Mascari <[EMAIL PROTECTED]> writes: > > > > > > > > > > > This is not something new. SunOS, AIX, HPUX, etc. all have (at > > > > > > one time or another) considerable BSD roots. And yet FreeBSD > > > > > > still exists... All GPL does is 'poison' the pot by prohibiting > > > > > > commercial spawns which may leverage the code. > > > > > > > > > > GPL doesn't prohibit commercial spawns - it just requires you to send > > > > > the source along. > > > > > > > > So if someone offers $$$ for implementation of Postgres > > > > feature XYZ I don't have to make that code open source? > > > > > > You don't have to tell the world they can have it for free - you can > > > sell it, and develop it by demand. > > > > > > > Only need to ship the code to the one paying > > > > > > Yes. > > > > Now I don't want to ship the source code. My customer would > > be happy with a patched 8.2.3 binary as long as I'm > > responsible to patch future versions until I release the > > sources. Is that OK? > > You don't have to give the customer the source, as long as you > gurantee that he gets it (for cost of distribution) if he wants it. Wordy, but how can I prevent him to ask for? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
[EMAIL PROTECTED] (Jan Wieck) writes: > Trond Eivind Glomsrød wrote: > > [EMAIL PROTECTED] (Jan Wieck) writes: > > > > > Trond Eivind Glomsrød wrote: > > > > Mike Mascari <[EMAIL PROTECTED]> writes: > > > > > > > > > This is not something new. SunOS, AIX, HPUX, etc. all have (at > > > > > one time or another) considerable BSD roots. And yet FreeBSD > > > > > still exists... All GPL does is 'poison' the pot by prohibiting > > > > > commercial spawns which may leverage the code. > > > > > > > > GPL doesn't prohibit commercial spawns - it just requires you to send > > > > the source along. > > > > > > So if someone offers $$$ for implementation of Postgres > > > feature XYZ I don't have to make that code open source? > > > > You don't have to tell the world they can have it for free - you can > > sell it, and develop it by demand. > > > > > Only need to ship the code to the one paying > > > > Yes. > > Now I don't want to ship the source code. My customer would > be happy with a patched 8.2.3 binary as long as I'm > responsible to patch future versions until I release the > sources. Is that OK? You don't have to give the customer the source, as long as you gurantee that he gets it (for cost of distribution) if he wants it. -- Trond Eivind Glomsrød Red Hat, Inc.
Re: [GENERAL] lztext and compression ratios...
[EMAIL PROTECTED] (Jan Wieck) writes: > One thing to keep in mind is that the LZ algorithm you're > thinking of must be distributable under the terms of the BSD > license. If it's copyrighted or patented by any third party, > not agreeing to these terms, it's out of discussion and will > never appear in the Postgres source tree. Especially the LZ > algorithm used in GIF is one of these show-stoppers. As long as you brought it up: how sure are you that the method you've used is not subject to any patents? The mere fact that you learned it from someone who didn't patent it does not guarantee anything --- someone else could have invented it independently and filed for a patent. If you can show that this method uses no ideas not found in zlib, then I'll feel reassured --- a good deal of legal research went into zlib to make sure it didn't fall foul of any patents, and zlib has now been around long enough that it'd be tough for anyone to get a new patent on one of its techniques. But if SLZ has any additional ideas in it, then we could be in trouble. There are an awful lot of compression patents. regards, tom lane
Re: [GENERAL] lztext and compression ratios...
Jeffery Collins wrote: > I have been looking at using the lztext type and I have some > questions/observations. Most of my experience comes from attempting to > compress text records in a different database (CTREE), but I think the > experience is transferable. First of all I welcome any suggestions/input to the compression code I've implemented. Seems you're experienced in this area so keep going and hammer down any of my points below. You should know that the "lztext" type will disappear soon and be replaced with the general "all varlena types are potentially compressable" approach of TOAST. > My typical table consists of variable length text records. The average > length record is around 1K bytes. I would like to compress my records > to save space and improve I/O performance (smaller records means more > records fit into the file system cache which means less I/O - or so the > theory goes). I am not too concerned about CPU as we are using a 4-way > Sun Enterprise class server. So compress seems like a good idea to me. > > My experience with attempting to compress such a relatively small > (around 1K) text string is that the compression ration is not very > good. This is because the string is not long enough for the LZ > compression algorithm to establish really good compression patterns and > the fact that the de-compression table has to be built into each > record. What I have done in the past to get around these problems is > that I have "taught" the compression algorithm the patterns ahead of > time and stored the de-compression patterns in an external table. Using > this technique, I have achieved *much* better compression ratios. The compression algorithm used in "lztext" (and so in TOAST in the future) doesn't have a de-compression table at all. It's based on Adisak Pochanayon's SLZ algorithm, using or . A just tells how far to go back in the OUTPUT-buffer and how many bytes to copy from OUTPUT to OUTPUT. Look at the code for details. My design rules for the compression inside of Postgres have been - beeing fast on decompression - beeing good for relatively small values - beeing fast on compression The first rule is met by the implementation itself. Don't underestimate this design rule! Usually you don't update as often as you query. And the implementation of TOAST requires a super fast decompression. The second rule is met by not needing any initial decompression table inside of the stored value. The third rule is controlled by the default strategy of the algorithm,(unfortunately)hardcoded into utils/adt/pg_lzcompress.c. It'll never try to compress items smaller than 256 bytes. It'll fallback to plain storage (for speed advantage while decompressing a value) if less than 20% of compression is gained. It'll stop match loookup if a backward match of 128 or more bytes is found. > So my questions/comments are: > > - What are the typical compression rations on relatively small (i.e. > around 1K) strings seen with lztext? Don't have that small items handy. But a table containing a file path and it's content. All files where HTML files. From - To | count(*) | avg(length) | avg(octet_length) ---+--+-+-- 1024 - 2047| 14 |1905 | 1470 2048 - 4095| 67 |3059 | 1412 4096 - 8191| 45 |5384 | 2412 8192 - | 25 | 17200 | 6323 ---+--+-+-- all| 151 |5986 | 2529 > - Does anyone see a need/use for a generalized string compression > type that can be "trained" external to the individual records? Yes, of course. Maybe "lztext" can be a framework for you and we just tell the toaster "never apply your lousy compression on that" (it's prepared for). > - Am I crazy in even attempting to compress strings of this relative > size? My largest table correct contains about 2 million entries of > roughly 1k size strings or about 2Gig of data. If I could compress this > to about 33% of it's original size (not unreasonable with a trained LZ > compression), I would save a lot of disk space (not really important) > and a lot of file system cache space (very important) and be able to fit > the entire table into memory (very, very important). Noone is crazy attempting to improve something. It might turn out not to work well, or beeing brain damaged from the start. But someone who never tries will miss all his chances. Final note: One thing to keep in mind is that the LZ algorithm you're think
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: > [EMAIL PROTECTED] (Jan Wieck) writes: > > > Trond Eivind=?iso-8859-1?q?_Glomsr=F8d?= wrote: > > > Mike Mascari <[EMAIL PROTECTED]> writes: > > > > > > > This is not something new. SunOS, AIX, HPUX, etc. all have (at > > > > one time or another) considerable BSD roots. And yet FreeBSD > > > > still exists... All GPL does is 'poison' the pot by prohibiting > > > > commercial spawns which may leverage the code. > > > > > > GPL doesn't prohibit commercial spawns - it just requires you to send > > > the source along. > > > > So if someone offers $$$ for implementation of Postgres > > feature XYZ I don't have to make that code open source? > > You don't have to tell the world they can have it for free - you can > sell it, and develop it by demand. > > > Only need to ship the code to the one paying > > Yes. Now I don't want to ship the source code. My customer would be happy with a patched 8.2.3 binary as long as I'm responsible to patch future versions until I release the sources. Is that OK? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [GENERAL] proposed improvements to PostgreSQL license
Ron Peterson wrote: > your software to make any concessions?". Of course you do. The > question is just what concessions do you require before granting use of > your product. Any statement to the effect that BSD is "really free" is > just navel gazing mumbo jumbo. Good points - alot of. Just that the above has a little flaw. We're not discussing "what concessions" the END-USER has to make before USING it. We ask "what restrictions" does a license apply to a DEVELOPER? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [GENERAL] Need help with error
Steven Saner <[EMAIL PROTECTED]> writes: > I will probably restart the postmaster tonight and make sure that > logging is being done. Then if it happens again we might have more to > go on. If you're going to do that, please install 7.0.2 first, else the log likely won't tell us much anyway ... regards, tom lane
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
Ron, probably the best example to reassure you here is Illustra/Informix, which is based on the old Berkeley Postgres code. A group of people at Berkeley "forked" the Postgres code into the closed Illustra system, but it survived as Postgres95, then later PostgreSQL when Marc and Bruce got started. As a number of people have said, if someone (like Great Bridge or anyone else) ever took the then-current PostgreSQL code proprietary, it would still remain as an open source project - and believe me, there are plenty of people who would rather work on it as an open source project than a proprietary death-spiral. We think the proprietary software development model for large scale projects (operating systems, databases, wide-ranging applications) is stupid and dead. We don't think open source is going away - in fact, we think it's the way most software is going to be developed in the future. There will certainly be companies that try and fork off open source projects and make a quick buck; they will fail. As I understand your concern, you don't want to make a learning investment in something you think is open source, only to have it go closed? I think I can safely say that PostgreSQL as an open source project will never go away - the momentum is too strong, the product is too good, the developers are too committed, for that to happen. Best, Ned Ron Peterson wrote: > I'm not trying to rankle the developers who have benefited me so much by > promoting the GPL. I'm just trying to protect myself as a consumer from > being left in the cold when the product I've spent so much time learning > and implementing suddenly goes proprietary. > > Sorry to be cynical, but as a consumer, I can't help seeing BSD licenses > as good old bait and switch. And this discussion doesn't reassure me > otherwise. > > Sure, the code can fork. SunOS, AIX, HPUX are good examples. Examples > of the kind of code forking and corporatism I thought, I hoped, the > world was moving away from. > > > Ron Peterson > [EMAIL PROTECTED]
[GENERAL] Question about tape backup of online database.
I'd like to know what hardware and software people use to perform tape backup of an online database on Linux. I would imagine the following might work(?): 1. Use RAID mirroring of the disk the db is on onto 2 two or more other disks. 2. When it is time to do the backup, disconnect one of the disks from the mirror and then dump the whole disk partition to a tape(s). 3. Reconnect the disk back to the mirror and let it begin rebuilding. Right now, I don't even have SCSI! If you can tell me your setup and backup procedure, I'd be grateful. -- Robert
Re: [GENERAL] Need help with error
On Wed, Jul 05, 2000 at 04:29:16PM -0400, Tom Lane wrote: > Steven Saner <[EMAIL PROTECTED]> writes: > > Using Postgres 7.0 on BSDI 4.1 > > For the last several days we are getting errors that look like this: > > > Error: cannot write block 0 of krftmp4 [adm] blind. > > > An interesting thing is that in this example, krftmp4 is a table that > > the user that got this error message would not have accessed in any > > way. > > Right --- that's implicit in the blind-write logic. A blind write > means trying to dump out a dirty page from the shared buffer pool > that belongs to a relation your own backend hasn't touched. > > Since the write fails, the dirty block remains in the shared buffer > pool, waiting for some other backend to try to dump it again and fail > again :-( > > The simplest recovery method is to restart the postmaster, causing a new > buffer pool to be set up. > > However, from a developer's perspective, I'm more interested in finding > out how you got into this state in the first place. We thought we'd > fixed all the bugs that could give rise to orphaned dirty blocks, which > was the cause of this type of error in all the cases we'd seen so far. > Perhaps there is still a remaining bug of that kind, or maybe you've > found a new way to cause this problem. Do you have time to do some > investigation before you restart the postmaster? > > One thing I'd like to know is why the write is failing in the first > place. Have you deleted or renamed the krftmp4 table, or its containing > database adm, probably not too long before these errors started > appearing? Well, we have had this database version/configuration in operation for a month or so. We rebooted the server July 1 as part of our normal maintenance procedure. It has been after that that we have begun seeing these problems. The adm database has been around for a long time. The krftmp4 table is not the only table that I have seen listed in these error messages. > > When this happens, it seems that the backend dies, which > > ends up causing the backend connections for all users to die. > > That shouldn't be happening either; blind write failure is classed as > a simple ERROR, not a FATAL error. Does any message appear in the > postmaster log? Is a corefile dumped, and if so what do you get from > a backtrace? Unfortunatly, I don't believe that there is any postmaster log. I will probably have to restart the postmaster and redirect the stdout to a file or something. As far as I can tell there are no core files being created. I will probably restart the postmaster tonight and make sure that logging is being done. Then if it happens again we might have more to go on. Steve
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
Mike Mascari wrote: > > Why do you continue to insist that GPL is superior to BSD? GPL is > BSD *with restrictions*. If someone comes along and sweeps up the > major developers: > > A) Good for the major developers - they deserve to have large > sums of cash thrown their way, particularly for many of them who > have been working on this *for years* > > B) The moment it happens, the project forks and another "Marc" > out-there offers to host development on his machine and the > process begins again. PostgreSQL exists despite Illustra's > existence. > > This is not something new. SunOS, AIX, HPUX, etc. all have (at > one time or another) considerable BSD roots. And yet FreeBSD > still exists... All GPL does is 'poison' the pot by prohibiting > commercial spawns which may leverage the code. If someone makes > some money selling CommercialGres by integrating replication, > distributive, and parallel query, good for them. Is perhaps GPL more restrictive for *developers*? And BSD more restrictive for *consumers*? As a consumer I prefer the GPL. But Mike's point is well taken. I agree that the GPL is rather idealistic. It makes it very difficult, almost impossible, for someone to make money doing software development. Is there a middle ground? Somewhere where perhaps I can be assured that *someday* in the not-so-distant future I, as a consumer, will have access to source code? Is there any such thing as a license with built-in time limits? Reasonably short time limits, as opposed to those provided by the U.S. patent office? Or is there a way to write an open-source license that allows developers to make money? I know, I know, there are too many licenses already. But if talented hard working people can't make a living, there's a problem. This will probably sound very stupid, but would it be possible to write a license that said something to the effect of "if you are a big corporate commercial interest worth more than $X, you must donate $Y to postgresql.org."? I'm not trying to rankle the developers who have benefited me so much by promoting the GPL. I'm just trying to protect myself as a consumer from being left in the cold when the product I've spent so much time learning and implementing suddenly goes proprietary. Sorry to be cynical, but as a consumer, I can't help seeing BSD licenses as good old bait and switch. And this discussion doesn't reassure me otherwise. Sure, the code can fork. SunOS, AIX, HPUX are good examples. Examples of the kind of code forking and corporatism I thought, I hoped, the world was moving away from. Ron Peterson [EMAIL PROTECTED]
[GENERAL] Scoring
Any tips on how to efficiently score fields with altavista-like query
strings?
I currently use the following PL/Perl function, which unfortunatly is
rather slow, even though I have already simplified it quite a bit...
# Example: SELECT id, score(description, 'a?pha -"beta gamma"') FROM
table;
CREATE FUNCTION score(TEXT, VARCHAR) RETURNS INT2 AS
'
my @regex = ();
my $score = 0;
$_[1] =~ s{(-)?"(.+?)"}{ push(@regex, $1 . $2); () }egs;
push(@regex, split(/\\s/, $_[1]));
foreach (@regex)
{
s/\\?/\\./g;
if (s/^-//)
{
return 0 if ($_[0] =~ /\\b$_/i);
}
else
{
my @matches = ();
@matches = $_[0] =~ /\\b$_/gi;
return 0 unless scalar @matches;
$score += scalar @matches or return 0;
}
}
return $score;
'
LANGUAGE 'plperl';
--
Eric Jain
Re: [GENERAL] Need help with error
"Philip Poles" <[EMAIL PROTECTED]> writes: > I'm not sure if this is relevant, but I've seen similar errors occur > when there are too many open files on the filesystem (running Linux RH > 6.2). I'm not sure if this problem is in the backend or the Linux > kernal, or somewhere else, not being very conversant in such matters > myself, but I did have our admin increase the limit for number of open > files. Good point. If you are at the system limit on number of open files, blind writes would fail where regular writes do not (in 7.0.* and earlier --- this is fixed for 7.1). However, if your kernel file table is full, the symptoms are usually visible all over the place not just in Postgres, so I'm not sure that this explains Steven's problem. I would recommend to Steven that he update to 7.0.2 soon, since there is some additional debugging logic in 7.0.2 that logs the kernel error code when a blind write fails --- that would give us some more info about the underlying problem. Of course an update implies a postmaster restart which will make the problem go away, so unless he knows how to reproduce it I'd prefer to investigate first... regards, tom lane
Re: [GENERAL] Need help with error
Greetings... I'm not sure if this is relevant, but I've seen similar errors occur when there are too many open files on the filesystem (running Linux RH 6.2). I'm not sure if this problem is in the backend or the Linux kernal, or somewhere else, not being very conversant in such matters myself, but I did have our admin increase the limit for number of open files. As far as I recall, when this happens, the postmaster tries to reset all currently running backends. I don't think I've seen it dump core, but I can reproduce the situation fairly easily (by running a hundred or so concurrent 7 table join queries) to find out...I'll try it on Friday, if I get a chance. Steven, I have no knowledge of how BSDI behaves, but might this have something to do with your problem? It seems to me as though postgres winds up with a LOT of open files when processing complex queries - is this actually the case, or should I be looking elsewhere for the cause of this problem? -Philip P.S. Tom - I haven't actually been able to reproduce that problem I was having with hash indicies...it just went away...and I know nothing has changed, except maybe the load on the server...I'll keep trying, maybe I can get a bug report in about it after all. - Original Message - From: Tom Lane <[EMAIL PROTECTED]> To: Steven Saner <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, July 05, 2000 4:29 PM Subject: Re: [GENERAL] Need help with error Steven Saner <[EMAIL PROTECTED]> writes: > Using Postgres 7.0 on BSDI 4.1 > For the last several days we are getting errors that look like this: > Error: cannot write block 0 of krftmp4 [adm] blind. > An interesting thing is that in this example, krftmp4 is a table that > the user that got this error message would not have accessed in any > way. Right --- that's implicit in the blind-write logic. A blind write means trying to dump out a dirty page from the shared buffer pool that belongs to a relation your own backend hasn't touched. Since the write fails, the dirty block remains in the shared buffer pool, waiting for some other backend to try to dump it again and fail again :-( The simplest recovery method is to restart the postmaster, causing a new buffer pool to be set up. However, from a developer's perspective, I'm more interested in finding out how you got into this state in the first place. We thought we'd fixed all the bugs that could give rise to orphaned dirty blocks, which was the cause of this type of error in all the cases we'd seen so far. Perhaps there is still a remaining bug of that kind, or maybe you've found a new way to cause this problem. Do you have time to do some investigation before you restart the postmaster? One thing I'd like to know is why the write is failing in the first place. Have you deleted or renamed the krftmp4 table, or its containing database adm, probably not too long before these errors started appearing? > When this happens, it seems that the backend dies, which > ends up causing the backend connections for all users to die. That shouldn't be happening either; blind write failure is classed as a simple ERROR, not a FATAL error. Does any message appear in the postmaster log? Is a corefile dumped, and if so what do you get from a backtrace? regards, tom lane
Re: [GENERAL] PostgreSQL 7.1
Mitch Vincent wrote: > I was sitting here reading about TOAST and 7.1 and another question came > into my mind.. I looked on the web page for some information about features > to be added in 7.1 and an approximate 7.1 release date.. I found information > on the TOAST feature as well as Referential Integrity but nothing else.. If > I missed it please just point me in the right direction, if not I'd like to > as about the approximate time of 7.1 arriving in a stable form and if full > text indexing is going to be a part of 7.1.. The project page you've seen was an idea I had several month ago. I had a big success with it since I got co-developers for FOREIGN KEY. It was the first time I something in an open source project with related developers, and the result was stunning - even for me. Unfortunately, none of the other "inner-circle" developers catched up that idea. Maybe all they're doing is not of the naturethatthey would gain anything from co- developers/volunteers. Not an answer to your real question, more like a kick in the A.. of my colleagues. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
[GENERAL] Indexing of geometric data
Greetings, I'm investigating the use of PostgreSQL to maintain a database of mapping data. My dataset currently stored latitudes and longitudes as fixed-precision integers (ie, 37.234 is stored as 37234) in separate columns: one for latitude, one for longitude. Postgres has geometric data types, such as point, line, etc, but I'm a little leary of using them because of performance reasons. For one, the internal representation of a point is a pair of double-precision floating point numbers. For a dataset containing millions of points, working with floats could be expensive, both in storage and computation costs. Second, I want to be able to do queries like "find all line segments (or points) that overlap or intersect with a given bounding box." I'm afraid that without an appropriate index on the set of data points, a query like that will be extremely slow. So my questions are: what data structure is used to index a set of points? Is it a spatially-oriented structure, such as a quadtree, that would make queries like the example above very fast? Can Postgres be adapted to use integers instead of floats to store point coordinates? Thanks! Barry
Re: [GENERAL] Need help with error
Steven Saner <[EMAIL PROTECTED]> writes: > Using Postgres 7.0 on BSDI 4.1 > For the last several days we are getting errors that look like this: > Error: cannot write block 0 of krftmp4 [adm] blind. > An interesting thing is that in this example, krftmp4 is a table that > the user that got this error message would not have accessed in any > way. Right --- that's implicit in the blind-write logic. A blind write means trying to dump out a dirty page from the shared buffer pool that belongs to a relation your own backend hasn't touched. Since the write fails, the dirty block remains in the shared buffer pool, waiting for some other backend to try to dump it again and fail again :-( The simplest recovery method is to restart the postmaster, causing a new buffer pool to be set up. However, from a developer's perspective, I'm more interested in finding out how you got into this state in the first place. We thought we'd fixed all the bugs that could give rise to orphaned dirty blocks, which was the cause of this type of error in all the cases we'd seen so far. Perhaps there is still a remaining bug of that kind, or maybe you've found a new way to cause this problem. Do you have time to do some investigation before you restart the postmaster? One thing I'd like to know is why the write is failing in the first place. Have you deleted or renamed the krftmp4 table, or its containing database adm, probably not too long before these errors started appearing? > When this happens, it seems that the backend dies, which > ends up causing the backend connections for all users to die. That shouldn't be happening either; blind write failure is classed as a simple ERROR, not a FATAL error. Does any message appear in the postmaster log? Is a corefile dumped, and if so what do you get from a backtrace? regards, tom lane
RE: [GENERAL] SQL Server Question (Way OFF TOPIC SORRY)
if memory serves, after the insert do a: SELECT @@IDENTITY but why would you want to use m$ sql server? it doesn't even run on linux... :-) -tim. -Original Message- From: Mirko Geffken To: PostgreSQL General Sent: 7/5/00 3:34 PM Subject: [GENERAL] SQL Server Question (Way OFF TOPIC SORRY) Hi, I know this is way off topic (with this being a PostgreSQL mailing list), but I couldn't find one. Does anyone know of a SQL Server mailing list. In case anybody knows the answer here, here is my question: I want to insert into a table with an identity field and get the identity field's value returned immediately e.g. CREATE TABLE x ( id IDENTITY(1,1), y INT ); INSERT INTO x(y) VALUES (2) In Oracle you can do something like: x:=INSERT INTO x(y) VALUES (2) RETURNING id (forgot exact syntax) Does anyone know of a safe (meaning works with concurrent users) solution for SQL Server? Thanks for your time and I apologize for the off topic message Mirko
Re: [GENERAL] responses to licensing discussion
At 02:19 PM 7/5/00 -0500, [EMAIL PROTECTED] wrote: > >Jan Wieck wrote: > >> I'm in doubt why none of the other open source projects ever >> felt the need to enforce license agreement in this way while >> most commercial players do. Maybe it's something we don't >> have to worry about, but what if so? What if we all have >> already one foot in jail and just don't know? > >This is exactly the the kind of sentiment that the UCITA proponents >sought to make as widespread as possible. > >> Oh boy, what >> about all the patches, modules, whatnot I contributed to >> other open source projects during the past 20 years? Can I >> sleep well tonight? > >They thought about that, too. UCITA is designed to be applied >retroactively, so you can sleep well knowing that there's nothing you >can do to prevent the Maryland residents from suing you for the >damages they suffered from your code over the last 20 years. Now if it >is true that the UCITA was meant to be a weapon of intimidation, it >seems to have started working: everybody is at least concerned, if not >scared. But it definitely goes overboard with its retroactive >capability, which actually makes it less intimidating: what's the use >in worrying about the future if we all have one foot in jail because >of our deeds in the past? > >Back to work, folks ... > >--Gene > not being from maryland but, i would think that the constitution's prohibition against ex post facto laws would prevent retro-active applications of laws, if the usa actually followed the constitution; but that's another topic... mikeo
Re: [GENERAL] PostgreSQL 7.1
"Mitch Vincent" <[EMAIL PROTECTED]> writes: > I was sitting here reading about TOAST and 7.1 and another question came > into my mind.. I looked on the web page for some information about features > to be added in 7.1 and an approximate 7.1 release date.. I found information > on the TOAST feature as well as Referential Integrity but nothing else.. If > I missed it please just point me in the right direction, if not I'd like to > as about the approximate time of 7.1 arriving in a stable form and if full > text indexing is going to be a part of 7.1.. AFAIK there are no plans on the table to do more with full text indexing; at least none of the core developers are working on it. (If someone else is and I've forgotten, my apologies.) Currently the plans for 7.1 look like this: * WAL (assuming Vadim gets it done soon) * TOAST (pretty far along already) * new fmgr (fmgr itself done, still need to turn crank on converting built-in functions) * better memory management, no more intraquery memory leaks (about half done) * some other stuff, but I think those are all the "big features" that anyone has committed to get done * whatever else gets done meanwhile We were shooting for going beta around Aug 1 with release around Sep 1, but don't hold us to that ;-). Notably missing from this list is OUTER JOIN and other things that depend on querytree redesign (such as fixing all the restrictions on views). We've agreed to put that off till 7.2 in hopes of keeping the 7.1 development cycle reasonably short. Not sure what else will be in 7.2, but the querytree work will be. > I ask because if 7.1 is going to include full text indexing natively and is > going to arrive pretty soon, I might not continue on this project as I have > been (the new full text index trigger).. Seems like you should keep at it. regards, tom lane
Re: [GENERAL] responses to licensing discussion
Jan Wieck wrote: > I'm in doubt why none of the other open source projects ever > felt the need to enforce license agreement in this way while > most commercial players do. Maybe it's something we don't > have to worry about, but what if so? What if we all have > already one foot in jail and just don't know? This is exactly the the kind of sentiment that the UCITA proponents sought to make as widespread as possible. > Oh boy, what > about all the patches, modules, whatnot I contributed to > other open source projects during the past 20 years? Can I > sleep well tonight? They thought about that, too. UCITA is designed to be applied retroactively, so you can sleep well knowing that there's nothing you can do to prevent the Maryland residents from suing you for the damages they suffered from your code over the last 20 years. Now if it is true that the UCITA was meant to be a weapon of intimidation, it seems to have started working: everybody is at least concerned, if not scared. But it definitely goes overboard with its retroactive capability, which actually makes it less intimidating: what's the use in worrying about the future if we all have one foot in jail because of our deeds in the past? Back to work, folks ... --Gene
[GENERAL] pg_shadow constraint ?
hi, i have a question about pg_shadow and constraints on it. someone left our employ and i did a dropuser on his id. later, when i did a pg_dump none of the tables created by him were dumped. i added him back thru createuser so that i could do a valid pg_dump. i tried to create a unique index on pg_shadow on usesysid with the intention of creating a foreign key from pg_class to the shadow table to save me from myself. :) create unique index usesysid_idx on pg_shadow(usesysid); CREATE then i attempt to create a foreign key from pg_class: alter table pg_class add constraint fk_relowner foreign key (relowner) references pg_shadow(usesysid); NOTICE: ALTER TABLE ... ADD CONSTRAINT will create implicit trigger(s) for FOREIGN KEY check(s) ERROR: Index 'pg_shadow_name_index' does not exist so i do a \d on pg_shadow: testx=# \d pg_shadow ERROR: Index 'pg_shadow_name_index' does not exist there were no indexes on pg_shadow when i started and i don't know why i would be getting this index error message after creating a unique index. i'm guessing that i cannot create such an index on pg_shadow because it causes some sort of internal problems. what i wanted to do was create a "STOP" for attempting to drop a user if that user still owns objects? with a lot of databases i thought it'd be easier for the system to tell me if such a situation existed than my searching through for that info. any suggestions would be welcome! mikeo
[GENERAL] Need help with error
Using Postgres 7.0 on BSDI 4.1 For the last several days we are getting errors that look like this: Error: cannot write block 0 of krftmp4 [adm] blind. An interesting thing is that in this example, krftmp4 is a table that the user that got this error message would not have accessed in any way. The user was trying to do an update of a different table in the adm database. When this happens, it seems that the backend dies, which ends up causing the backend connections for all users to die. Can someone give me an idea of what this error message means, and perhaps how to fix it? I haven't been keeping up with the list lately, so please forgive me if this has been covered recently. Thanks.
[GENERAL] SQL Server Question (Way OFF TOPIC SORRY)
Hi, I know this is way off topic (with this being a PostgreSQL mailing list), but I couldn't find one. Does anyone know of a SQL Server mailing list. In case anybody knows the answer here, here is my question: I want to insert into a table with an identity field and get the identity field's value returned immediately e.g. CREATE TABLE x ( id IDENTITY(1,1), y INT ); INSERT INTO x(y) VALUES (2) In Oracle you can do something like: x:=INSERT INTO x(y) VALUES (2) RETURNING id (forgot exact syntax) Does anyone know of a safe (meaning works with concurrent users) solution for SQL Server? Thanks for your time and I apologize for the off topic message Mirko
Re: [GENERAL] Re: [ANNOUNCE] Re: [HACKERS] proposed improvements to PostgreSQL license
Simon Brooke wrote: > Ned Lilly wrote: > > > > > Two states have adopted UCITA - Virginia and Maryland. Maryland has > > > an October 1, 2000, effective date, but requires that its laws will > > > only apply if there is a reasonable connection with the state. > > > Virginia has an effective date of July 1, 2001, but does not require > > > a connection with the state and thereby gives somewhat greater > > > assurance that UCITA will apply to all Postgres-related dealings, > > > wherever they occur. > > Not here in Scotland, they won't. If people in the United States feel > that United States law prevents them contributing to Open Source > projects, that is a local problem which should be addressed locally - by > lobbying their representatives to change the law. Lobbying is an art of influencing representatives to cater for someone else's needs. This is how the UCITA proposal emerged in the first pace: through an extensive lobbying by those badly reputed industries who started losing in the marketplace to open source/free software, or became apprehensive of the possibility of such losses. Aside from the money and other forces involved in lobbying, the reasoning in support of UCITA has a lot of brainwashing potential: why should one allow free software to exist at all, let alone without liability by default, in the same time when the free health care, free police and free money market are banned from existence. This is, I guess, the kind of uniformity sought by the UCITA -- what else does that "U" stand for? With that said, how likely do you think is that all software developers of Maryland together, even backed up by all law professors and practicing lawyers, will be able to overturn the decision to adopt UCITA by simply annoying their representatives? Considering that most lawmakers and lobbyists of the World live in a 20-mile wide area in Virginia and Maryland centered around the U.S. Capitol, and that the economy of these states depends on the lobbying industry more than Jamaica on tourism, I wouldn't bet my lunch. BTW, I don't think that UCITA has terribly good chances of becoming the United States law. While many states are still evaluating the proposal, a few others including Illinois, where I happen to live, have declined to even consider it for evaluation. Now picture this: in a not so distant future you visit a web site whose title page says: "Residents of Europe, Canada, Illinois and other free countries, please go ahead. Residents of Virginia and Maryland, please kindly follow this link. Your local law requires us to harass you some more before you can download. Avoiding this harassment by making an inappropriate selection voids our responsibility. How's that as an alternative to a pop-up license statement? I wonder what Dilbert has to say about this. --Gene
[GENERAL] newbie question
is it possible to pull a column from a postgres table then have it linked via html and php to the corresponding row. If so how would that be accomplished?
Re: [GENERAL] proposed improvements to PostgreSQL license
* The Hermit Hacker <[EMAIL PROTECTED]> [000705 12:03] wrote: > > just to curtail this while thread to a certain point ... switching the > license to GPL is *not* on the table, nor has it every been, nor will it > ever be ... Good to hear, I was getting worried for a bit that the code might become uselessly encumbered by a non-opensource friendly license. Ignore the hype, keep the code _free_. thanks, -Alfred
Re: [GENERAL] proposed improvements to PostgreSQL license
just to curtail this while thread to a certain point ... switching the
license to GPL is *not* on the table, nor has it every been, nor will it
ever be ...
On Wed, 5 Jul 2000, Ron Peterson wrote:
> Ned,
>
> Thanks for inviting the community to participate in this discussion. I
> wonder, though, if you might like to invite the participation of a wider
> audience. While I'm sure the subscribers to this list are fervent about
> all matters related to PostgreSQL, perhaps the subject matter deserves
> the scrutiny of a larger and more diverse community. I might suggest
> that beloved cesspool of civil discord - Slashdot.
>
> As for the particulars of your proposal, I'd like to suggest, and I see
> others agree, that it would still be premature to table the discussion
> of GPL vs. BSD style licensing. If for no other reason than if not now,
> when?
>
> There seem to be two primary objectives here: (1) protect contributers
> from liability. (2) maintain the code as open source.
>
> I don't really understand liability issues or how they relate to the GPL
> (or any other license for that matter). I'm certainly 100% in favor of
> protecting PostgreSQL developers from court claims, of course. So I'm
> not going to chime in about liability issues.
>
> One objection to the use of the GPL has been that it has never been
> tested in court. That may soon change. See
> http://www.linuxplanet.com/linuxplanet/reports/2000/1/.
>
> Then of course there's the discussion about which license is really more
> "free". True, a BSD style license places no restrictions on how someone
> may use the code. So you are "free to innovate", as it were. Isn't
> anyone worried that PostgreSQL might become it's own competition?
>
> > ...we're big fans of the current Berkeley license; we find it
> > more "open" than other open source licenses, in the sense that the
> > user/hacker has almost total freedom as to what he wants to do with
> > the code.
> -Ned Lilly
>
> To me, it's the difference between the freedom of anarchy, and the
> freedom afforded by good government. Licenses are inherently
> restrictive. That's the whole point of having them. This is true even
> for BSD style licenses. So the question is not "do you ask the users of
> your software to make any concessions?". Of course you do. The
> question is just what concessions do you require before granting use of
> your product. Any statement to the effect that BSD is "really free" is
> just navel gazing mumbo jumbo.
>
> I keep seeing mention of the "fact" that the "business community"
> prefers a BSD style license to the GPL. Might I ask for details on how
> this conclusion was reached?
>
> > We've also found, through some rather extensive market
> > research, that the business community (to which we'll be selling
> > products and services) vastly prefers it over GPL, or hybrids like
> > Mozilla, etc.
> -Ned Lilly
>
> I would submit that most businesses don't know the difference. Perhaps
> they need some education.
>
> I would also submit that that the manner in which a survey was conducted
> could greatly influence it's own results.
>
> Q: "Do you prefer a GPL or BSD style license?"
> A: "What's the difference?"
> Q: "A BSD style license gives you more flexibility in how you administer
> changes you might make to the software."
> A: "Well, then BSD of course."
>
> Nevermind that this same business might be running half of its back end
> services using GPL'd software.
>
> How about "Would you like to know that you can take advantage of
> contributions made to this software by anyone working on it worldwide?",
> or "Would you like a *guarantee* that the core development team won't
> duck tail and make you start paying for certain improvements?"
>
> I'm not accusing anyone of malicious intentions. I'm just saying that
> the only *guarantee* of good intentions is the license associated with
> the software.
>
> Throw my response into the survey: my business would prefer GPL'd
> software.
>
> -Ron-
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [GENERAL] Primary key question
Richard Rowell wrote: > > I'm creating a database with 20 tables or so. I have come to the > table that will likely tie many of these tables together, that is > every single field in this table will be a foriegn key. My question > is, rather then include all of the fields into the primary key of this > table, and therefore include all of these fields into any table that > will reference this one, would it be politically correct to just give > each entry an integer as a primary key and scan for dupes in a > trigger? It sure seems like it would cut down on the complexity of > the whole thing... If I understand correctly, it sounds like what you want to do is establish a UNIQUE constraint on your foreign keys, and add a sequenced integer to be the primary key for this table. E.G. - CREATE TABLE test ( fkey1 INTEGER REFERENCES ..., fkey2 INTEGER REFERENCES ..., id SERIAL PRIMARY KEY, UNIQUE(fkey1,fkey2) ); Ron Peterson [EMAIL PROTECTED]
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this more palatable?
On Wed, 5 Jul 2000, The Hermit Hacker wrote:
> Personally, from all the 'legal' issues that FreeBSD has gone through over
> the years, especially recently with the BSDi/FreeBSD merger and the whole
> cryptology merger, I would think they would have been the first to
> adopt/change their BSD license to something else, and I've never even seen
> discussions on it ...
The only thing that comes close are the periodic discussions (ignored by
FBSD developers) about the removal of the 'offensive' mascot. ;-)
Top Ten Gratuitous Discussions:
1. FreeBSD v. Linux
2. GPL v. BSD licence
3. Removal of 'Chuckie' (Berkeley Daemon) from BSD
in favour of something less 'Satanic' or 'Demonic'
4. (Official) renaming of 'Chuckie' so as not offend McKusick
over the popular (mis)perception that the Berkeley Daemon
is (nick)named 'Chuckie'
5. MySQL v. Postgres
6. RedHat v. Debian v. SuSe
7. Why was Slackware not involved in the above discussion
8. Perl v. Python
9. Coke v. Pepsi
lastly:
10. Altering the PG licence...I agree with *my perception* of Scrappy's
position: If FBSD get nervous and changes their licence, Pg should
follow suit. Otherwise it seems counterproductive.
Anyway, thanks for the great code. I promise not to abuse it.
I promise not to sue anyone if I am too damn stupid to use it properly.
SVCMC - Center for Behavioral Health
Thomas Good tomg@ { admin | q8 } .nrnet.org
IS Coordinator / DBA Phone: 718-354-5528
Fax: 718-354-5056
Powered by: PostgreSQL s l a c k w a r e FreeBSD:
RDBMS |-- linux The Power To Serve
Re: [GENERAL] responses to licensing discussion
Philip Warner wrote: > > At 02:36 5/07/00 +0200, Jan Wieck wrote: > > > >So the problem left are binary distributions. > > > > There might be a technical solution here; I *think* RPM allows pretty > flexible running of scripts. We could only make binary distributions for > architectures that support RPM. RPM does allow this. But it does sort of screw up the distribution process to have all these dialogs in the RPMS. With redhat, I fire up the installation and walk away because redhat has been pretty religious about suppressing dialogs. With debian, I fire up the install, then keep comimg back to the machine every 15 minute because one package or another is waiting for me to enter a few keystrokes (NOTE to distribution partisans - there are things I like better about each distribution - I'm not advocating one over the other here) > We could also pop up a message on 'initdb', or the first time the > postmaster is started etc etc. On initdb seems reasonable, and gets around the issue above. > We might even want to be really paranoid, and warn each user when they > first go into psql...I provide WWW services, and part of that service is > access to PG. My agreements always limit my liabilities, but these users > never see the BSD waiver of PG... Why don't they? The installer accepts the license. It is then the role of the installer to ensure that all the people he/she supports understand how the software may be used, IMHO. For instance, unless I am the installer of M$ Office, I don't see the shrink wrap. Which means nearly all users in an office don't see the shrink wrap. But that seems okay to M$. I would urge that this issue of actively acknowleging license not be carried too far. In the extreme, imagine connecting to a MS IIS web server, it checks afor a unique cookie on your machine and says "Hmm - I don't know that this user has ever connected to IIS before - they have not been to my site - so I'd better pop up a dialog first" IMHO, it is your responsibilty os the provider of services to make your users aware of the various licenses that apply. If PG adopts something like the above mechanism, then you may well want to have a dialog for your users to do just that. But PG should not dictate how I interact with my users. Instead of disturbing my web users, maybe there should be an additional requirement in the license that says people who repackage postgres, or make it available through other means, are responsible for ensuring that the users are aware of the license requirements. Then a RedHat type vendor can add the PG license to their intro screen, or they can leave a message in initdb active. PG could provide tools to make notification on first connect easier, but I do not believe that needs to be enforced by PG. Come to think of it, this sort of propagation clause may be needed anyway. Otheriwse, I could download PG by clicking through your license screen on the website, then post it to an ftp repository somewhere. Once I've done that, it seems to me that someone downloading from my ftp site would never acknowlege the license, and there you are on the hook again. Right now the BSD handles this passive for the passive case - the license stipulates that the license must appear in derivative products. If active acknowlegement is required (not that I like the idea, but if it is required to protect developers) then that active aknowlegement must somehow stipulate that all deriviative products need to include some similar form of active acknowlegement. Otherwise you will never be able to distribute source, and it won't be open source anymore. -- Karl DeBisschop
Re: [GENERAL] responses to licensing discussion
On Wed, 5 Jul 2000, Gilles DAROLD wrote: > Hi, > > I have some problem to understand why you have to change the PostgreSQL > Licence > agreement. You are really making confusion into my mind. For me I have this > licence > come with all my distributions : > > PostgreSQL Data Base Management System (formerly known as Postgres, > then as Postgres95). > > Copyright (c) 1994-7 Regents of the University of California > > Permission to use, copy, modify, and distribute this software and its > documentation for any purpose, without fee, and without a written > agreement > is hereby granted, provided that the above copyright notice and this > paragraph and the following two paragraphs appear in all copies. > > etc... > > This the most open licence you can do, isn't it ? > > It just come a commercial company and things must change, why ? There's > already companies > saling PostgreSQL as a commercial product (see Adabas or Ingres it's looks > like Postgres !). > > If you do OSS and give all the code to the community for free, what do you > have to be protected from > that is not done ? > > Your discussion seems to applies to all current programmers of PostgreSQL, > but what about > the olders, are they agree with this ? And if the copyrigth belong to the > University of California > what programmers can do to protect their works ? > > Apology my poor understanding but it smell something wrong for me. > Is PostgreSQL Inc. have the same need than Landmark/Great Bridge > concerning this licence migration ? Nope ... this is purely a perceived problem by the Landmark/Great Bridge folk ... one that I can't count how many OSS projects out there don't/haven't felt a need for *shrug*
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
On Wed, 5 Jul 2000, Philip Warner wrote: > At 00:24 5/07/00 -0400, Mike Mascari wrote: > >> > >> Am I correct in saying that you agree that the GPL is where we should be, > >> but you want people to go there of their own free will? > > > >Why do you continue to insist that GPL is superior to BSD? GPL is BSD > >*with restrictions* > > I don't. The above was a question to Jan. > > I have stated in the past that I would prefer PG to be GPL, but that is > based on my perception of PG as a 'strategic resource' for my company. The > GPL Vs. BSD discussion is a religious war that will only be resolved in > time. I do, honestly, hope Jan is right about the convergence of open > source and industry. Philip ... I abhor GPL myself, which is why PostgreSQL will never fall under it ... I think it is just this side of 'MicroSloth evil' in that it creates way more restrictions on code that are necessary. Its been around so long that ppl have been effectively brainwashed into thinking that "this is the only open source license" ... You cannot close source open source ... unless ppl don't care. If someone were to come along and try, someone else comes along and forks the code off at the point *just before* the license changed and continues along their own thread. Quite frankly, that person forking it off would be me, since PostgreSQL was never intended to be closed source ... ... it doesn't matter if the code is under BSD or GPL, that fork can (and will) happen ... with GPL, its near impossible to do ... with BSD, its easier, but it buys little for the commercial enterprise doing so ... I was going to say that what BSD buys someone over GPL is the ability to create modules taht are binary only, but even GPL allows for that ... *shrug* > >A) Good for the major developers - they deserve to have large > >sums of cash thrown their way, particularly for many of them who > >have been working on this *for years* > > I totally agree. This can happen under GPL. If I were a company wanting to > develop PG, the source would be less of an issue than access to the core > developers who are the real resource. As Jan has said elsewhere, keeping > source secret is a waste of effort. Okay, so BSD vs GPL matters not here ... > >B) The moment it happens, the project forks and another "Marc" > >out-there offers to host development on his machine and the > >process begins again. PostgreSQL exists despite Illustra's > >existence. > > No problem here but wasted effort. And BSD vs GPL matters not here ... > In summary of my position: > > 1. I am happy to continue with vanilla BSD + extra warranty & liability > disclaimers. This is my feeling too ... I won't agree to changing the license over to a "under juristiction of ...", nor will I agreee with the "slam this in front of ppls faces and force them to read it ...". Personally, from all the 'legal' issues that FreeBSD has gone through over the years, especially recently with the BSDi/FreeBSD merger and the whole cryptology merger, I would think they would have been the first to adopt/change their BSD license to something else, and I've never even seen discussions on it ... Putting the license up as a README on the ftp site, and maybe including it as part of the download page ... no probs, not obnoxious ... hell, how many ppl even read the license on sites that require a 'I agree'?
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this more palatable??
Thus spake Jan Wieck > Right. Someone who doesn't want to make his code "FREE" in > the entire meaning of this word but want to make it open for > any non-commercial use should choose it. IMHO the GPL While I am a proponent of keeping the BSD style license, there is nothing in the GPL about using code for commercial use one way or the other. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
[Fwd: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?]
Mike Mascari wrote: > Why do you continue to insist that GPL is superior to BSD? GPL is > BSD *with restrictions*. If someone comes along and sweeps up the > major developers: > > A) Good for the major developers - they deserve to have large > sums of cash thrown their way, particularly for many of them who > have been working on this *for years* > My understanding is that BSD allows someone to take the code commercial without consulting the original developers at all. With GPL, a company would have to negotiate an alternative license with the copyright holders in order to use the code for a closed source commercial product. This would ensure that the copyright holders receive some compensation. (Multiple licensing is a common strategy; e.g., ReiserFS if offered under GPL and commercial licensing. It is also possible to let users choose one of several licenses, so you can release your code under BSD and GPL and let users decide which they prefer, although this could create additional problems with integrating contributed code.) With BSD you are basically saying that anyone can use the code anyway they want, even if they take it and sell it as part of a commercial closed source product. I'm also happy if major postgres developers get sums of cash thrown their way, but why does BSD make that more likely? Also, I will point out that the GPL allows anyone to make closed source modifications to code as long as they do not redistribute the modifications. Its perfectly fine to modify the code and use the modified version within an organization. Placing modifications under the GPL only applies when these modifications are distributed to others. I believe some of the GPL 'poison' comments incorrectly implied that the GPL restricts organizations from making closed source modifications for internal use. T. -- Timothy H. Keitt National Center for Ecological Analysis and Synthesis 735 State Street, Suite 300, Santa Barbara, CA 93101 Phone: 805-892-2519, FAX: 805-892-2510 http://www.nceas.ucsb.edu/~keitt/
[GENERAL] How to lock a table
We're trying to use a unique-identifier scheme in a database; and therefore we need to put a lock on a table. Is there some way to do this using the PyGres (python) adapter? -Morten - How to reply to email: http://home.sol.no/~vidaandr/news/OBSquoting.html (norsk) http://home.sol.no/~vidaandr/news/FAQquoting.html (english) Who is the bigger fool? The fool or the fool who follows him?
Re: [GENERAL] REFERENCES troubles
Delete the , after KEY and give owner a datatype and everything works fine. I have tested. Jesus. On Wed, 5 Jul 2000, planx plnetx wrote: > > > CREATE TABLE workers( > > > namevarchar(30), > > > firstname varchar(30), > > > id_personal decimal(10)NOT NULL UNIQUE PRIMARY KEY, > > > ); > > > > > > CREATE TABLE payements( > > > date_of date, > > > owner REFERENCES workers(id_personal) > > > );
[GENERAL] Re: [HACKERS] Revised Copyright: is this more palatable?
Philip Warner wrote: > I do still own copyright, but I can't prevent people using it in a > PG-derived project. But I *can* prevent them using it in software to run a > meat-grinder, assuming that software is not recognizably a PG derived > database (as perceived by a reasonable person). This could be relevant to > Jan who wrote compression code, although I suspect he's philosophically > opposed to preventing his actual source code being used in, eg, "The New > Fangled Microsoft Disk Compressor, using advanced Compression Technology > (tm)". Especially the compression code was only coding. The underlying algorithm (slightly modified) was taken from a 10+ years old usenet article and is the idea of Adisak Pochanayon. If anyone on earth can make money out of it, I don't have a problem with that. This includes M$ and any other company with bad reputation. But if there's a bug in my code causing severe damage, I don't want to get sued for it. That's all. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this morepalatable?
Mike Mascari wrote: > This is not something new. SunOS, AIX, HPUX, etc. all have (at > one time or another) considerable BSD roots. And yet FreeBSD > still exists... All GPL does is 'poison' the pot by prohibiting > commercial spawns which may leverage the code. If someone makes > some money selling CommercialGres by integrating replication, > distributive, and parallel query, good for them. Let them! It's good for the customer too, because he mustn't wait until we lazy dogs implement all that. If they are smart, they will contribute it to the open source tree sometimes after having their ROI. Otherwise they run the risk of getting stuck someday when their changes don't apply any more to our tree but they are still responsible for it's functionality. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [HACKERS] Re: [GENERAL] Revised Copyright: is this more palatable??
Philip Warner wrote: > > Am I correct in saying that you agree that the GPL is where we should be, > but you want people to go there of their own free will? Right. Someone who doesn't want to make his code "FREE" in the entire meaning of this word but want to make it open for any non-commercial use should choose it. IMHO the GPL includes "this is the one and only truth and must propagate up into everything started on something that once went under this license". Who am I to restrict my code in that way? Can I see the future? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
Re: [GENERAL] REFERENCES troubles
>From: "Robert B. Easter" <[EMAIL PROTECTED]>
>To: "planx plnetx" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: [GENERAL] REFERENCES troubles
>Date: Tue, 4 Jul 2000 18:38:28 -0400
>
>On Tue, 04 Jul 2000, planx plnetx wrote:
> > I get this error when creating a database:
> >
> > CREATE TABLE workers(
> > namevarchar(30),
> > firstname varchar(30),
> > id_personal decimal(10)NOT NULL UNIQUE PRIMARY KEY,
> > );
> >
> > CREATE TABLE payements(
> > date_of date,
> > owner REFERENCES workers(id_personal)
> > );
> >
> >
> > IT gimme error!!!
> > why this isn't right?
> > the postgres documentation seem say to do in this manner...
>
>You could try something like this instead:
>
>CREATE TABLE workers(
> id_personal SERIAL PRIMARY KEY,
> nameVARCHAR(30),
> firstname VARCHAR(30)
>);
>CREATE TABLE payements(
> date_of DATE,
> owner REFERENCES workers
>);
>
>PRIMARY KEY implies UNIQUE NOT NULL
>SERIAL will be an INTEGER DEFAULT nextval('workers_id_personal_seq') so
>they
>get a number automatically.
Yes thanks, but why I can't specify a column like the manual say:
REFERENCES workers(id_personal)?
how the simple REFERENCES workers can get the primary key? maybe it is
automatiQUE
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [GENERAL] Glade or wxPython and Postgresql
>From: Bill Barnes <[EMAIL PROTECTED]> >To: postgres general mail list <[EMAIL PROTECTED]> >Subject: [GENERAL] Glade or wxPython and Postgresql >Date: Mon, 3 Jul 2000 20:20:22 -0400 > >Hello list: > >Has anybody on the list put one of these combinations together? > >Thanks, >Bill Barnes > I am utilizing glade/C/libpq/postgresql7 Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [GENERAL] Anyone using ReiserFS in production work? (or advise against it?)
>From: "Randall Parker" <[EMAIL PROTECTED]> >Reply-To: "Randall Parker" <[EMAIL PROTECTED]> >To: "PostgreSQL General" <[EMAIL PROTECTED]> >Subject: [GENERAL] Anyone using ReiserFS in production work? (or advise >against it?) >Date: Tue, 04 Jul 2000 15:02:17 -0700 > >The title says it all: Is this a foolhardy or prudent and wise move at this >time? > >Has anyone run Postgres databases on ReiserFS volumes under heavy enough >load and for long enough to get a sense of how stable it is? > >Anyone tried pulling the power plug under heavy load to find out if >ReiserFS is less prone to volume corruption than ext2 under these >circumstances? > > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: [GENERAL] responses to licensing discussion
Hi, I have some problem to understand why you have to change the PostgreSQL Licence agreement. You are really making confusion into my mind. For me I have this licence come with all my distributions : PostgreSQL Data Base Management System (formerly known as Postgres, then as Postgres95). Copyright (c) 1994-7 Regents of the University of California Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. etc... This the most open licence you can do, isn't it ? It just come a commercial company and things must change, why ? There's already companies saling PostgreSQL as a commercial product (see Adabas or Ingres it's looks like Postgres !). If you do OSS and give all the code to the community for free, what do you have to be protected from that is not done ? Your discussion seems to applies to all current programmers of PostgreSQL, but what about the olders, are they agree with this ? And if the copyrigth belong to the University of California what programmers can do to protect their works ? Apology my poor understanding but it smell something wrong for me. Is PostgreSQL Inc. have the same need than Landmark/Great Bridge concerning this licence migration ? Regards, Gilles DAROLD
Re: [GENERAL] Combining two SELECTs
Tom Lane wrote: > > "Eric Jain" <[EMAIL PROTECTED]> writes: > > Any ideas how the following two statements could be combined into a > > single one? > > > SELECT DISTINCT host, url, id > > INTO TEMP > > FROM log > > WHERE > > host IN (SELECT host FROM robots) > > AND status IN (200, 304); > > > SELECT host, COUNT(*) AS hits > > FROM TEMP > > GROUP BY host > > ORDER BY hits DESC; > > Offhand I do not think you can do this in one "simple" SQL query, > because the SQL query semantics require that GROUP BY grouping occurs > before DISTINCT processing, whereas you want the other order. > > > For now, the temp table seems like a good workaround. > And splitting some complex queries in simpler ones (using temp tables) can increase performance, depending on the query. Regards, Guillaume Perréal - Stagiaire MIAG Cemagref (URH), Lyon, France Tél: (+33) 4.72.20.87.64
Re: [GENERAL] Combining two SELECTs
"Eric Jain" <[EMAIL PROTECTED]> writes: > Any ideas how the following two statements could be combined into a > single one? > SELECT DISTINCT host, url, id > INTO TEMP > FROM log > WHERE > host IN (SELECT host FROM robots) > AND status IN (200, 304); > SELECT host, COUNT(*) AS hits > FROM TEMP > GROUP BY host > ORDER BY hits DESC; Offhand I do not think you can do this in one "simple" SQL query, because the SQL query semantics require that GROUP BY grouping occurs before DISTINCT processing, whereas you want the other order. (I'm assuming you need exactly these semantics, and not closely- related ones as someone else suggested.) By 7.2 or so, we hope to support sub-SELECTs in FROM, which'd let you do this along the lines of SELECT host,COUNT(*) FROM (SELECT DISTINCT host, ...) GROUP BY ... You might try to do it today by defining the SELECT DISTINCT as a view and then selecting from the view with GROUP BY, but I expect it won't work --- presently, views are implemented by expanding the view macro-style, so they don't work for any case that you couldn't write out as a single SQL-compliant query. (Again, we hope to make this work better in 7.2.) For now, the temp table seems like a good workaround. regards, tom lane
