Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from
At 9:18 PM -0500 3/9/06, Bruce Momjian wrote: Robert Treat wrote: On Thursday 09 March 2006 20:16, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: I am not sure, but I think that Alvaro's point is the copyright doesn't matter in this instance. It is the license that does. Certainly, but if the file says Copyright PostgreSQL Global Development Group then it's reasonable to assume that the intended license is the one in the top COPYRIGHT file. If the file says copyright someone else then this requires a bit of a leap of faith. If the file actually contains its own license language (as Jan's files did till just now) then that's unquestionably an independent license that you have to pay attention to if you're redistributing. It is very good to keep everything consistent. Yup, that's all we're after. It would be very good if it wasn't likely to cause more legal trouble than it will help. Removing copyrights from actual people to be replaced with a non-existent legal entity might be construed as eliminating any copyright claim at all. Even if you could get the global development group recognized legally as the copyright holder, you've only consolidated things for someone to attempt to gain ownership of the code. With the BSD license, there really isn't any restriction to enforce, so the copyright owner is pretty meaningless. IANAL, but as I understand things, it's not possible to disclaim ownership of something. That's why the BSD license is preferable to public domain. In most legal jurisdictions, liability (for whatever) belongs to the copyright holder. By adding a license, particularly one as liberal as the BSD license, you're setting rules for how the code can be used, _and those rules can disclaim liability_. Essentially, if you take responsibility for something, you can legally insist that others use it responsibly (and if they don't, they broke your rules so it's not your fault.) Again, IANAL, but my $0.02 would be that copyright always stay with some legal entity, either the individual authors, or some actual holding company. Distributed individual copyrights (like the WU-FTPD example) seem to provide the most protection for preserving the license status quo, since everyone on the list would have to agree to change it. OTOH, an LLC or similar entity can shield individual authors from legal liability. (Though the license itself might be sufficient.) -pmb ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Fwd: Apple Darwin disabled fsync?
At 12:38 AM -0500 2/20/05, Tom Lane wrote: Dominic Giampaolo [EMAIL PROTECTED] writes: I believe that what the above comment refers to is the fact that fsync() is not sufficient to guarantee that your data is on stable storage and on MacOS X we provide a fcntl(), called F_FULLFSYNC, to ask the drive to flush all buffered data to stable storage. I've been looking for documentation on this without a lot of luck (man fcntl on OS X 10.3.8 has certainly never heard of it). It's not completely clear whether this subsumes fsync() or whether you're supposed to fsync() and then use the fcntl. My understanding is that you're supposed to fsync() and then use the fcntl, but I'm not the filesystems expert. (Dominic, who wrote the original message that I forwarded, is.) I've filed a bug report asking for better documentation about this to be placed in the fsync man page. radar://4012378 Also, isn't it fundamentally at the wrong level? One would suppose that the drive flush operation is going to affect everything the drive currently has queued, not just the one file. That makes it difficult if not impossible to use efficiently. I think the intent is to make the fcntl more accurate in time, as the ability to do so appears in hardware. One of the advantages Apple has is the ability to set very specific requirements for our hardware. So if a block specific flush command becomes part of the ATA spec, Apple can require vendors to support it, and support it correctly, before using those drives. On the other hand, as Dominic described, once the hardware is external (like a firewire enclosure), we lose that leverage. At 12:42 PM -0500 2/20/05, Greg Stark wrote: Dominic Giampaolo [EMAIL PROTECTED] writes: In most cases you do not need such a heavy handed operation and fsync() is good enough. Really? Can you think of a single application for which this definition of fsync is useful? Kernel buffers are transparent to the application, just as the disk buffer is. It doesn't matter to an application whether the data is sitting in a kernel buffer, or a buffer in the disk, it's equivalent. If fsync doesn't guarantee the writes actually end up on non-volatile disk then as far as the application is concerned it's just an expensive noop. I think the intent of fsync() is closer to what you describe, but the convention is that fsync() hands responsibility to the disk hardware. That's how every other Unix seems to handle fsync() too. This gives you good performance, and if you combine a smart fsync()ing application with reliable storage hardware (like an XServe RAID that battery backs it's own write caches), you get the best combination. If you know you have unreliable hardware, and critical reliability issues, then you can use the fcntl, which seems to be more control than other OSes give. -pmb ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Fwd: Apple Darwin disabled fsync?
Date: Sat, 19 Feb 2005 17:59:21 -0800 From: Dominic Giampaolo [EMAIL PROTECTED] Subject: Re: bad fsync? (A.M.) To: [EMAIL PROTECTED] MySQL makes the following claim at: http://dev.mysql.com/doc/mysql/en/news-4-1-9.html InnoDB: Use the fcntl() file flush method on Mac OS X versions 10.3 and up. Apple had disabled fsync() in Mac OS X for internal disk drives, which caused corruption at power outages. First of all, is this accurate? A pointer to some docs or a tech note on this would be helpful. The comments about fsync() are wrong... On MacOS X, fsync() always has and always will flush all file data from host memory to the drive on which the file resides. The behavior of fsync() on MacOS X is the same as it is on every other version of Unix since the dawn of time (well, since the introduction of fsync anyway :-). I believe that what the above comment refers to is the fact that fsync() is not sufficient to guarantee that your data is on stable storage and on MacOS X we provide a fcntl(), called F_FULLFSYNC, to ask the drive to flush all buffered data to stable storage. Let me explain in more detail. With fsync() even though the OS writes the data through to the disk and the disk says yes I wrote the data, the data is not actually on permanent storage. Unless you explicitly disable it, all disks have a write buffer which holds data you've written. The disk buffers the data you wrote until it decides to flush it to the platters (and the writes may not be in the order you wrote them). If you lose power or the system crashes before the data is written, you can wind up in a situation where only some of your data is actually on disk. What is worse is that even if you write blocks A, B and C, call fsync() and then write block D you may find after rebooting that blocks A and D are on disk but B and C are not (in fact any ordering of A, B, C, and D is possible). While this may seem like a rare case it is not. In fact if you sit down and pull the plug on a system you can make it happen in one or two plug pulls. I have even gone so far as to watch this behavior with a logic analyzer on the ATA bus: I saw the data for two writes come across the ATA cable, the drive replied and said the writes were successful and then when we rebooted the data from the second write was correct on disk but the data from the first write was not. To deal with this we introduced the F_FULLFSYNC fcntl which will ask the drive to flush all of its buffered data to disk. When an app needs to guarantee that data is on disk it should use F_FULLFSYNC. In most cases you do not need such a heavy handed operation and fsync() is good enough. But in an app like a database, it is essential if you want transactional integrity. Now, a little bit more detail: on ATA drives we implement F_FULLFSYNC with the FLUSH_TRACK_CACHE command. All drives sold by Apple will honor this command. Unfortunately quite a few firewire drive vendors disable this command and do not pass it to the drive. This means that most external firewire drives are not reliable if you lose power or the system crashes. We can't work-around that unless we ask the drive to disable the write cache completely (which hurts performance quite badly -- and even that may not be enough as some drives will ignore that request too). So in summary, I believe that the comments in the MySQL news posting are slightly confused. On MacOS X fsync() behaves the same as it does on all Unices. That's not good enough if you really care about data integrity and so we also provide the F_FULLFSYNC fcntl. As far as I know, MacOS X is the only OS to provide this feature for apps that need to truly guarantee their data is on disk. Hope this clears things up. --dominic ---(end of broadcast)--- TIP 3: 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] location of the configuration files
At 12:31 AM -0500 2/13/03, mlw wrote: The idea that a, more or less, arbitrary data location determines the database configuration is wrong. It should be obvious to any administrator that a configuration file location which controls the server is the right way to do it. Isn't the database data itself a rather significant portion of the 'configuration' of the database? What do you gain by having the postmaster config and the database data live in different locations? -pmb ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3b3 passes on MacOSX 10.2.1
At 1:30 AM -0500 11/1/02, Tom Lane wrote: I said: Peter Bierman [EMAIL PROTECTED] writes: Perhaps the change from gcc2.x to 3.x changed floats a bit? Could be. We had previous reports of the same diff on OSX 10.2 with a G4 processor, so I was wondering if it was hardware or software differences (geometry-powerpc-darwin.out matches exactly on my G3 laptop running OSX 10.1). I have a 10.2 CD and am planning to update sometime soon to verify this by experiment. I have done the update and now I get the ...40473 output on the same hardware that useta pass. So it's clearly a software-version issue. Is it worth carrying two expected files for OS X 10.1 and 10.2? I'm inclined to think not, and am leaning towards updating the expected file. Comments? I'm 90% certain that the difference is caused by GCC 2.95 vs 3.1. (10.0 10.1 vs 10.2) If you can easily pick the right file based which GCC compiled it, that'd be ideal. -pmb ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3b3 passes on MacOSX 10.2.1
At 4:31 PM -0500 11/1/02, Tom Lane wrote: Peter Bierman [EMAIL PROTECTED] writes: At 1:30 AM -0500 11/1/02, Tom Lane wrote: Is it worth carrying two expected files for OS X 10.1 and 10.2? I'm inclined to think not, and am leaning towards updating the expected file. Comments? I'm 90% certain that the difference is caused by GCC 2.95 vs 3.1. Probably. I had to do a bunch of updates to my 10.1.x system, but I can now verify that 10.1.5 builds and runs 7.3b3 regression test with no failures. If you can easily pick the right file based which GCC compiled it, that'd be ideal. No, we can't easily do that. We could conditionalize it on the OS version, but I don't think it's worth the trouble. I've committed a change to the expected file so that OSX 10.2 will pass cleanly, and older versions will have the one-digit difference instead. That's fine. If someone gets ambitious, the uname -a from the two differing versions are: 10.1.5 Darwin bierpe3 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc 10.2.1 Darwin cmos.apple.com 6.1 Darwin Kernel Version 6.1: Fri Sep 6 23:24:34 PDT 2002; root:xnu/xnu-344.2.obj~2/RELEASE_PPC Power Macintosh powerpc This whole issue should go away in PG 7.4, unless someone objects to the current plan for making float output precision adjustable. We'll back off the number of displayed digits in the geometry test by one or two places, and hopefully need only one or a very few geometry comparison files. Excellent. -pmb ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] CVS TOT fails to build on MacOSX 10.2.1
So first off, what's the best way to tell from a cvs snapshot which release (if any) that snapshot is? I just (2pm) grabbed a full clean cvs checkout, and tried to run the regression tests. This is on a Macintosh G4/450 dual CPU with 512MB. 'make runcheck' in src/test/regress/ fails with: snip from src/test/regress/log/install.log rm -f libecpg.so \ ln -s libecpg.so.3.4.0 libecpg.so make -C preproc install make -C ../../../../src/port all make[6]: Nothing to be done for `all'. bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded make[5]: *** [preproc.h] Error 1 make[4]: *** [install] Error 2 make[3]: *** [install] Error 2 make[2]: *** [install] Error 2 make[1]: *** [install] Error 2 /snip -pmb ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] 7.3b3 passes on MacOSX 10.2.1
At 6:11 PM -0500 10/29/02, Neil Conway wrote: Peter Bierman [EMAIL PROTECTED] writes: So first off, what's the best way to tell from a cvs snapshot which release (if any) that snapshot is? configure.in, perhaps? Ah, thanks. 7.3b3 it is then. 'make runcheck' in src/test/regress/ fails with: bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded You need bison 1.50 or greater to build the new ecpg (due to a bison limitation). Ok. After upgrading to bison-1.75, all regression tests pass except: *** ./expected/geometry-powerpc-darwin.out Mon Dec 11 08:45:16 2000 --- ./results/geometry.out Tue Oct 29 15:40:56 2002 *** *** 127,133 ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140472) --- 127,133 ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140473) == Perhaps the change from gcc2.x to 3.x changed floats a bit? -pmb ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3b3 passes on MacOSX 10.2.1
*** ./expected/geometry-powerpc-darwin.out Mon Dec 11 08:45:16 2000 --- ./results/geometry.out Tue Oct 29 15:40:56 2002 *** *** 127,133 ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140472) --- 127,133 ! | (-10,0)| [(-100,200),(30,-40)] | (-9.99715942258202,15.3864610140473) == At 9:19 PM -0500 10/29/02, Bruce Momjian wrote: Yes, OSX 10.2.X seems to have this output on _some_ machines, but not others, and we can't seem to figure out why. Can you tell us more about your machine and cpu? It's a dual 450MHz G4 with 512MB RAM, running 10.2.1. Is there any particular type of Mac you'd like me to try it on? -pmb ---(end of broadcast)--- TIP 3: 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] Mac OS X: system shutdown prevents checkpoint
At 1:26 AM -0400 4/30/02, Tom Lane wrote: I've been looking into Francois Suter's recent reports of Postgres not shutting down cleanly on Mac OS X 10.1. Now here's what I see in the case of shutting down the OS X system: 2002-04-30 00:25:35 [376]DEBUG: pmdie 15 2002-04-30 00:25:35 [376]DEBUG: smart shutdown request ... and nothing more. Actual system shutdown (power down) occurred at approximately 00:26:06 by my watch, over thirty seconds later than the postmaster received SIGTERM. So there was plenty of time to do the checkpoint subprocess. (Indeed, I believe that thirty seconds is the grace period Darwin's init process allows SIGTERM'd processes before giving up and hard-killing them. So the system was actually sitting and waiting for the postmaster.) What we appear to have here is that the kernel is not allowing the postmaster to fork a checkpoint subprocess. But there's no indication that the postmaster got a fork() error return, either. Seems like it's just hung. Unfortunately, I don't have time right now to look into this myself, and because I just moved, I don't have a machine I can give someone an account on to try it themselves (PacBell says 20 days for DSL xfer). But I asked around, and got a pair of tips from the Mac OS X Core OS group. If you want to converse with either of the people named below, they're both active on the darwin-development mailing list. (http://lists.apple.com/mailman/listinfo/darwin-development) -pmb At 1:52 PM -0700 5/1/02, Jim Magee wrote: On Wednesday, May 1, 2002, at 01:34 PM, Peter Bierman wrote: Is fork() disallowed after shutdown starts? No, it's allowed. But, depending upon timing, the new process may be hammered with a SIGTERM right away (maybe even before main()). It is always very tricky to fork() as the result of a daemon getting a signal. They are often process group leader, and so their children may get the same signal they just got. POSIX is very ambiguous on whether a new process in the group should also get the signal while we're still delivering them, or whether it shouldn't because it wasn't in the group at the time the signal was first delivered). Both choices have their problems, and so developers have to deal with either case. Do you have signals masked off correctly before the fork()/exec()? Is fork really returning a PID in the parent, and it just looks like the child didn't make it to returning from its fork() call? There are some preparation things that happen in dyld and libc as part of returning fom fork in the child, and these run before we make it look like fork() returned in the child. If they encounter an error (maybe because the services they need to talk to are no longer available), they have nothing else to do but call _exit() - making it look like the child never returned from fork(). But in either the dydl/libc exit case, or the signal case, the parent should get a wait result indicating why the child went away so prematurely. If is was an exit(), maybe using vfork() will yield better results, as there is no need for child-side setup in the vfork() case. --Jim At 2:01 PM -0700 5/1/02, Matt Watson wrote: It could be that the child has blocked trying to contact a dead lookupd. ---(end of broadcast)--- TIP 3: 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
[HACKERS] Case sensitive file names
While checking out TOT pgsql today onto an HFS+ file system (case-preserving, case-insensitive), I hit the following CVS conflict: pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map pgsql/src/backend/utils/mb/Unicode/utf8_to_ALT.map HFS+ can not store two differerent files in a path that differs only by case. Mac OS X users will be grateful if you can find a way to rename one of these files. -pmb ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Regression failed Mac OSX
At 5:47 PM -0500 4/4/01, Neil Tiffin wrote: Using current cvs version on Mac OS X 10.0 test horology ... FAILED I can't reproduce this on a 10.0 (4K78) system. I just ran the regression tests from cvs HEAD downloaded @ 16:10 PDT on a G3/350. It also passed several dozen iterations on a G4/400 and a G4/450x2 running 10.0.1. Looping (make clean; make runcheck) in a shell while loop seems to eat all available disk space, but I don't think that's a PG bug. Oooh, while waiting for another check to pass, I read the pgsql-hackers archives, and I see that the horology test problem was because of daylight savings time (on all platforms). It appears to have been resolved, because current sources don't have the problem. -pmb ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Call for platforms
At 7:53 PM -0500 3/26/01, Tom Lane wrote: Thomas Lockhart [EMAIL PROTECTED] writes: "PPC750"? What's that? "PPC G3" might be more likely to mean something to onlookers ... Actually "G3" means nothing outside of Apple afaict. The 750 series is a follow-on to the 60x series, and there is a 7xxx series also. From my pov, using an accepted label, rather than a marketing (re)label, better indicates *what* this actually can run on. I'm not sure that I have it labeled correctly yet, but "G3" is not a step in the right direction. I found an apparently current "PowerPC CPU Summary" at http://e-www.motorola.com/webapp/sps/technology/tech_tutorial.jsp?catId=M943030621280 If accurate, the chip in this PowerBook is *not* a 750, since that tops out at 400 MHz. Apple offered this model in 400 and 500 MHz speeds, which makes it either a 7400 or 7410 chip ... Should I put "Mac G3" in the comment section? Yes, if you won't put it where it should be ;-). I'm still of the opinion that "G3" will mean something to a vastly larger population than "750" or "7400" would. The latter are "marketing relabels" too you know; Motorola's internal designation would probably be something else entirely. A "Me Too" from the peanut gallery. There are probably 1000x as many users that will recognize that they have a PowerPC G3 than will know they have a PPC750 or PPC7400. -pmb ---(end of broadcast)--- TIP 3: 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] 7.1 features list
At 9:43 PM -0400 12/17/00, The Hermit Hacker wrote: On Sat, 16 Dec 2000, Peter Bierman wrote: (BTW- tons of stuff at www.postgresql.org is busted. Searching mailing list archives for example.) Please provide URLs where you are trying to search ... we did extensive work over the past few weeks to speed up searching, and I tend randomly to make sure things are still running fine, and haven't had any problems with either speed or broken links ... Clicking on the "search" pic/link at http://www.postgresql.org/ always brought up a dialog (IE5-Mac) that said "the attempt to load http://www.postgresql.org/search.mpl" failed. But just now I pasted that URL into the location, and it loads fine. And now the pic/link works fine too. I have no idea what's with that. Just now I went to http://www.postgresql.org/mhonarc/pgsql-hackers/ typed 'foo' in the search field, and I get a dialog a few seconds later: "The attempt to load:"Accessing URL: http://www.postgresql.org/mhonarc/pgsql-hackers/search.mpl?stuff" (runs offscreen). Maybe it's some javascript that's trying to load a "still loading" page, and has a bogus URL with some explanatory text prepended? (Note the URL:"Accessing URL:http...") I loaded "http://www.postgresql.org/mhonarc/pgsql-hackers/search.mpl?" by hand, and then went back and tried a search again, and now it works. Dunno what's going on here. Since it never worked for me, I never tried loading the URL by hand. Obviously it's more complicated than the outright broken link that I thought it was, sorry about that. -pmb -- "Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make." http://joel.editthispage.com/stories/storyReader$51
Re: [HACKERS] 7.1 features list
At 3:16 PM -0500 12/16/00, Bruce Momjian wrote: Here is the list of features in 7.1. New Darwin/Mac OSX port (Bruce Hartzler) Not to be a snob, but I probably did 80% of this. (BTW- tons of stuff at www.postgresql.org is busted. Searching mailing list archives for example.) -pmb -- "Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make." http://joel.editthispage.com/stories/storyReader$51
Re: [HACKERS] beta testing version
At 5:17 PM -0500 12/3/00, mlw wrote: I honestly feel that it is wrong to take what others have shared and use it for the basis of something you will not share, and I can't understand how anyone could think differently. Yeah, it really sucks when companies that are in buisness to make money by creating solutions and support for end users take the hard work of volenteers, commit resources to extending and enhancing that work, and make that work more accessable end users (for a fee). Maybe it's unfair that the people at the bottom of that chain don't reap a percentage of the revenue generated at the top, but those people were free to read the license of the product they were contributing to. Ironically, the GPL protects the future income a programmer much bettter than the BSD license, becuase under the GPL the original author can sell the code to a commercial enterprise who otherwise would not have been able to use it. Even more ironically, the GPL doesn't prevent 3rd parties from feeding at the trough as long as they DON'T extend and enhance the product. (Though Red Hat and friends donate work back to maintain community support.) To me, Open Source is about admitting that the Computer Science field is in it's infancy, and the complex systems we're building today are the fundamental building blocks of tomorrow's systems. It is about exchanging control for adoption, a trade-off that has millions of case studies. Think Different, -pmb -- "Every time you provide an option, you're asking the user to make a decision. That means they will have to think about something and decide about it. It's not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that people have to make." http://joel.editthispage.com/stories/storyReader$51
Re: [HACKERS] beta testing version
And I really havn't seen much in the way of full featured products, complete with printed docs, 24 hour support, tutorials, wizards, templates, a company to sue if the code causes damage, GUI install, setup, removal, etc. etc. etc. Mac OS X. ;-) -pmb -- [EMAIL PROTECTED] "4 out of 5 people with the wrong hardware want to run Mac OS X because..." http://www.newertech.com/oscompatibility/osxinfo.html
