Re: [HACKERS] On file locking
Curt Sampson <[EMAIL PROTECTED]> wrote: > At any rate, it seems to me highly unlikely that, since the child has > the *same* descriptor as the parent had, that the lock would > disappear. It depends on the lock function. After fork(): o with flock() the lock continues to be held, but will be unlocked if any child process explicitly unlocks it o with fcntl() the lock is not inherited in the child o with lockf() the standards and manual pages don't say Boring reference material follows. flock = >From the NetBSD manual page: NOTES Locks are on files, not file descriptors. That is, file descriptors du- plicated through dup(2) or fork(2) do not result in multiple instances of a lock, but rather multiple references to a single lock. If a process holding a lock on a file forks and the child explicitly unlocks the file, the parent will lose its lock. The Red Hat Linux 8.0 manual page has similar wording. (No standards to check here -- flock() is not standardised in POSIX, X/Open, Single Unix Standard, ...) fcntl = The NetBSD manual page notes that these locks are not inherited by child processes: Another minor semantic problem with this interface is that locks are not inherited by a child process created using the fork(2) function. Ditto the Single Unix Standard versions 2 and 3. lockf() === The standards and manual pages that I've checked don't discuss fork() in relation to lockf(), which seems a peculiar ommission and makes me suspect that behaviour has varied historically. In practice I would expect lockf() semantics to be the same as fcntl(). Regards, Giles ---(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: [mail] Re: [HACKERS] Windows Build System
Curt Sampson wrote: > What I'm hearing here is that all we really need to do to "compete" with > MySQL on Windows is to make the UI a bit slicker. So what's the problem > with someone building, for each release, a set of appropriate binaries, and > someone making a slick install program that will install postgres, > install parts of cygwin if necessary, and set up postgres as a service? The non-code related parts of the Win32 port of PostgreSQL that are being looked at: + Working on the packaging bits (slick install program) already. Have created a project - pgsqlwin - on GBorg to hold any specific bits we need. http://gborg.postgresql.org/project/pgsqlwin/projdisplay.php First release of the *extremely alpha* "Proof of Concept" version is at: http://prdownloads.sourceforge.net/pgsql/PgSQL731wina1.exe?download + Concerned about including GPL stuff without having 100% totally investigated the ramifications for people including the Win32 version of PostgreSQL as a built-in part of their applications. Not going to commit anything even slightly GPL related to that GBorg project until it 100% safe to do so without affect our ability to release it as BSD. Have some preliminary information regarding this, but just need to wrap my head around it properly. Not going to look at it closely for another week or so. + It would be greatly helpful to have some way for the install program to automatically add the "Log in as a service" Win32 priviledge to the "postgres" user without having to instruct the user to do so. We can create the user automatically through a shell command, but no idea how to add that permission. If someone could do some Win32 API stuff to do it behind the scenes without a shell command even, that would be great. + The WinMaster project is a first go at creating a Win32 GUI command console for controlling the PostgreSQL service. It's still a bit too basic for real use though: http://gborg.postgresql.org/project/winmaster/projdisplay.php Further suggestions, volunteers, etc are totally welcome. :-) Regards and best wishes, Justin Clift > cjs -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(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] On file locking
On Fri, 31 Jan 2003, Tom Lane wrote: > Antti Haapala <[EMAIL PROTECTED]> writes: > > And from SunOS 5.8 flock > > Locks are on files, not file descriptors. That is, file > > descriptors duplicated through dup(2) or fork(2) do not > > result in multiple instances of a lock, but rather multiple > > references to a single lock. If a process holding a lock on > > a file forks and the child explicitly unlocks the file, the > > parent will lose its lock. Locks are not inherited by a > > child process. > > That seems self-contradictory. Yes. I note that in NetBSD, that paragraph of the manual page is identical except that the last sentence has been removed. At any rate, it seems to me highly unlikely that, since the child has the *same* descriptor as the parent had, that the lock would disappear. The other option would be that the lock belongs to the process, in which case one would think that a child doing an unlock should not affect the parent, because it's a different process cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [mail] Re: [HACKERS] Windows Build System
On Sat, 1 Feb 2003, Peter Eisentraut wrote: > Curtis Faith writes: > > >a) Running as a service is important as this the way NT/2000 > > administrators manage server tasks. The fact that PostgreSQL's Cygwin > > emulation doesn't do this is very indicative of inferior Windows > > support. > > No, it is indicative of the inability to read the documentation. > PostgreSQL on Cygwin runs as a service if and only if you ask it to. I would say that not supporting those who have an inability to read documentation would count as "inferior Windows support." :-) What I'm hearing here is that all we really need to do to "compete" with MySQL on Windows is to make the UI a bit slicker. So what's the problem with someone building, for each release, a set of appropriate binaries, and someone making a slick install program that will install postgres, install parts of cygwin if necessary, and set up postgres as a service? cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Linux.conf.au 2003 Report
On Fri, 31 Jan 2003, Kurt Roeckx wrote: > It's a good things that the socket interface can actually work > with all protocol! It doesn't only work with AF_INET, but also > AF_UNIX, and probably others. It's a good things that things > like socket(), bind(), connect() don't need to be replaced by > other things. Sure. But you still want to be able to say (and can say, in some [many?] socket API implementations) that you want to accept only IPv4 or only IPv6 connections. I also want to be able to say the same thing in my database. So probably, this means setting up separate types for IPv4 and IPv6 addresses, and a third type to hold both IPv4 and IPv6 addresses. That third type could also be extended to hold OSI, NS, and whatever other type of addresses people feel would be useful. I suppose another way of implementing this would be to set up some easy way to put a constraint on a column such that you could constrain it to hold only IPv4 or IPv6 addresses. And I would be interested to hear the opinions of those who want to put IPv4 and IPv6 addresses in the same type as to whether you do or do not support also putting ISO/OSI and Novell addresses into that type as well, and why or why not. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL, NetBSD and NFS
On Fri, 31 Jan 2003, mlw wrote: > . There are always issues with file locking across various > platforms. I recall reading about mmap issues across NFS a while ago... Postgres uses neither of these, IIRC, so that should be fine. (Actually, postgres does effectively use mmap for shared memory on NetBSD, but that's not mapping data on the NFS filesystem, so it's not an issue.) > The NFS client may also have isses with locking, fsync, and mmap. Any fsync problems would affect data integrity during a crash, but nothing otherwise. (Of course, I'm happy to be corrected on any of these issues, if someone can point out particular parts of postgres that would fail over NFS.) cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PERFORM] not using index for select min(...)
On Sat, Feb 01, 2003 at 15:21:24 -0500, Greg Stark <[EMAIL PROTECTED]> wrote: > Tom Lane <[EMAIL PROTECTED]> writes: > > That just means you need some way for aggregates to declare which records they > need. The only values that seem like they would be useful would be "first > record" "last record" and "all records". Possibly something like "all-nonnull > records" for things like count(), but that might be harder. I don't see how this is going to be all that useful for aggregates in general. min and max are special and it is unlikely that you are going to get much speed up for general aggregate functions. For the case where you really only need to scan a part of the data (say skipping nulls when nearly all of the entries are null), a DBA can add an appropiate partial index and where clause. This will probably happen infrequently enough that adding special checks for this aren't going to pay off. For min and max, it seems to me that putting special code to detect these functions and replace them with equivalent subselects in the case where an index exists (since a sort is worse than a linear scan) is a possible long term solution to make porting easier. In the short term education is the answer. At least the documentation of the min and max functions and the FAQ, and the section with performance tips should recommend the alternative form if there is an appropiate index. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] mysql -- cygwin
> I'm not sure what version of MySQL you were looking at, but that's > certainly doesn't seem to be the case anymore. I just checked: MySQL > 4.0.9 has ~435,000 LOC, PgSQL from CVS HEAD has ~372,000. Hmm, you got me there, tho this was some time back from the last version of the 3.x series. Merlin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] mysql -- cygwin
mysql does not have cygwin in the server, either static or otherwise. We looked at the code a while back and confirmed this. mysql has a much smaller code base than pg. If they did, it would be a very strange deal because you can link your app directly to the mysql server (for 200$...non GPL) which would be a weird interaction with cygwin license if it were static linked to the mysql server (it isn't). mysql does have some win32 isms in the code, notably asnch file i/o in some cases (mostly the import), which gives very fast data import speed (amazingly fast, even). In testing, this turned out to be the only thing fast about mysql on windows so we dropped the project. mysql on windows also seems to spend a lot of time waiting on mutexes and is not stable when canceling large queries in progress. Merlin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL, NetBSD and NFS
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > On Saturday 01 February 2003 14:43, Tom Lane wrote: >> What else was going on? As far as I can see, the code never does a >> semop unless it's waiting for some other backend process. > Nothing except the standard background processes are running. More and more bizarre. What is the hardware platform --- does it have TAS? regards, tom lane ---(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] PostgreSQL, NetBSD and NFS
On Saturday 01 February 2003 14:43, Tom Lane wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > > Here's the log. As you can see, nothing was logged after the COPY > > command. > > What else was going on? As far as I can see, the code never does a > semop unless it's waiting for some other backend process. Nothing except the standard background processes are running. The ktrace.out I gave the ftp address for has everything that that instance of PostgreSQL was doing. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PERFORM] not using index for select min(...)
Tom Lane <[EMAIL PROTECTED]> writes: > Kevin Brown <[EMAIL PROTECTED]> writes: > > Hmm...any chance, then, of giving aggregate functions a means of > > asking which table(s) and column(s) the original query referred to so > > that it could do proper optimization on its own? > > You can't usefully do that without altering the aggregate paradigm. > It won't help for min() to intuit the answer quickly if the query > plan is going to insist on feeding every row to it anyway. That just means you need some way for aggregates to declare which records they need. The only values that seem like they would be useful would be "first record" "last record" and "all records". Possibly something like "all-nonnull records" for things like count(), but that might be harder. > Don't forget that it would also need to be aware of whether there were > any WHERE clauses, joins, GROUP BY, perhaps other things I'm not > thinking of. > > In the end, the only reasonable way to handle this kind of thing is > to teach the query planner about it. Considering the small number > of cases that are usefully optimizable (basically only MIN and MAX > on a single table without any WHERE or GROUP clauses), and the ready > availability of a SQL-level workaround, it strikes me as a very > low-priority TODO item. All true, but I wouldn't be so quick to dismiss it as low-priority. In my experience I've seen the idiom "select min(foo) from bar" more times than I can count. The frequency with which this question occurs here probably is indicative of how much people expect it to work. And it's probably used by a lot of multi-database applications and in a lot of auto-matically generated code where it would be hard to hack in special purpose workarounds. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 port powerfail testing
> -Original Message- > From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]] > Sent: 01 February 2003 12:40 > To: Greg Copeland > Cc: Dave Page; PostgresSQL Hackers Mailing List; Tom Lane > Subject: Re: [HACKERS] Win32 port powerfail testing > > > Try it with FreeBSD's UFS and FreeBSD 5.0's new UFS2 > filesystems perhaps - or I could! OK thanks for the comments everyone. Due to the fact that I really need to do quite a few tests and this might take a fair while, I'm going to limit this to ext3 and NTFS5. I'm all for the Win32 port, but if there's one thing I firmly believe it's that we should stongly recommend Windows 2000+ with NTFS as a minimum OS in all our docs. At a push I might agree to NT4 :-) As there have been no objections to my test program, I'll assume everyone agrees that it should test what is required and therefore expect not to hear 'but you didn't do...' if I end up in the same predicament as Hannu's friend!! Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL, NetBSD and NFS
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > 100Mb instead of 100Mb -->1000Mb. I tried mounting with and without the TCP > option and it seemed to act the same but it was better than before. Now it > doesn't crash but trying to load a large table hangs. It gets to a point > where it is calling semop over and over getting a 0 return. It does that 81 > times in 0.989004 seconds and then hangs in the PostgreSQL code. It must be > in some sort of busy loop because there are no further system calls after the > last semop return and the CPU usage continues to climb. Very bizarre. Looks like the last page it read was block 104 (851968/8192) in file "/source/data/cert/base/16556/17063". Could you provide a formatted dump of that page? I'm partial to pg_filedump which you can get from http://sources.redhat.com/rhdb/tools.html. Use switches -f -i to get a reasonably complete dump. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL, NetBSD and NFS
On Saturday 01 February 2003 14:00, Tom Lane wrote: > What was the query it failed on, exactly? That last page it read > seems to be an empty index page --- it should have moved on to the > next index page, I'd think, rather than doing anything that could > hang up. Here's the log. As you can see, nothing was logged after the COPY command. It's possible that the file was corrupted. I will do a new test from scratch now that I am not switching speeds. -- 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. Feb 1 04:21:17 matrix pg_test[7432]: [3] DEBUG: connection: host=192.168.10.75 user=darcy database=cert Feb 1 04:21:17 matrix pg_test[7432]: [4] DEBUG: InitPostgres Feb 1 04:21:17 matrix pg_test[7432]: [5] DEBUG: StartTransactionCommand Feb 1 04:21:17 matrix pg_test[7432]: [6] DEBUG: query: select getdatabaseencoding() Feb 1 04:21:17 matrix pg_test[7432]: [7] DEBUG: ProcessQuery Feb 1 04:21:17 matrix pg_test[7432]: [8] DEBUG: CommitTransactionCommand Feb 1 04:21:17 matrix pg_test[7432]: [9] DEBUG: StartTransactionCommand Feb 1 04:21:17 matrix pg_test[7432]: [10] DEBUG: query: SELECT usesuper FROM pg_user WHERE usename = 'darcy' Feb 1 04:21:17 matrix pg_test[7432]: [11] DEBUG: ProcessQuery Feb 1 04:21:17 matrix pg_test[7432]: [12] DEBUG: CommitTransactionCommand Feb 1 04:21:17 matrix pg_test[7432]: [13] DEBUG: StartTransactionCommand Feb 1 04:21:17 matrix pg_test[7432]: [14] DEBUG: query: UPDATE "pg_class" SET "reltriggers" = 0 WHERE "relname" = 'certificate'; Feb 1 04:21:17 matrix pg_test[7432]: [15] DEBUG: ProcessQuery Feb 1 04:21:17 matrix pg_test[7432]: [16] DEBUG: CommitTransactionCommand Feb 1 04:21:17 matrix pg_test[7432]: [17] DEBUG: StartTransactionCommand Feb 1 04:21:17 matrix pg_test[7432]: [18] DEBUG: query: COPY "certificate" FROM stdin; Feb 1 04:21:17 matrix pg_test[7432]: [19] DEBUG: ProcessUtility: COPY "certificate" FROM stdin; ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL, NetBSD and NFS
What was the query it failed on, exactly? That last page it read seems to be an empty index page --- it should have moved on to the next index page, I'd think, rather than doing anything that could hang up. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL, NetBSD and NFS
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > That's a 4.7 MB file. The dump might be quite huge. I really just want to see the dump of that one page, and maybe the pages before and after it for comparison's sake. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL, NetBSD and NFS
On Saturday 01 February 2003 13:09, Tom Lane wrote: > Very bizarre. Looks like the last page it read was block 104 > (851968/8192) in file "/source/data/cert/base/16556/17063". Could you > provide a formatted dump of that page? I'm partial to pg_filedump which > you can get from http://sources.redhat.com/rhdb/tools.html. Use > switches -f -i to get a reasonably complete dump. That's a 4.7 MB file. The dump might be quite huge. I can send you the file itself (privately) if you want. Wouldn't that be even better? I can tell you what the file is. It is the primary key file for the certificate database which is the 8 million record table that I am trying to load. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Win32 port powerfail testing
On Sat, Feb 01, 2003 at 11:30:17AM -0600, Greg Copeland wrote: > On Sat, 2003-02-01 at 00:34, Adam Haberlach wrote: > > On Sat, Feb 01, 2003 at 12:27:31AM -0600, Greg Copeland wrote: > > > On Fri, 2003-01-31 at 14:36, Dave Page wrote: > > > Please go with XFS or ext3. There are a number of blessed and horror > > > stories which still float around about reiserfs (recent and old; even > > > though I've never lost data with it -- using it now even). > > > > > > Might be worth testing FAT32 on NT as well. Even if we don't advocate > > > it's use, it may not hurt to at least get an understanding of what one > > > might reasonably expect from it. I'm betting there are people just > > > waiting to run with FAT32 in the Win32 world. ;) > > > > You'd better go with NTFS. There are a number of blessed and horror > > stories which still float around about FAT32 (recent and old; even though > > I've never lost data with it -- using it now even now. > > > > Might be worth testing reiserfs on Linux as well. Even if we don't > > advocate it's use, it may not hurt to at least get an understanding of > > what one my reasonably expect from it. I'm better there are people > > just waiting to run with reiserfs in the Linux world. ;) > > > > Regards, and tongue firmly in cheek, > > Touche! :P > > While I understand and even appreciate the humor value, I do believe the > picture is slightly different than your "analysis". If we make > something that runs on Win32 platforms, might it also run on Win98, > WinME, etc.? Let's face the facts that should it also run on these > platforms, it's probably only a matter of time before someone has it > running on FAT32 (even possible on NT, etc). In other words, I'm fully > expecting the lowest common denominator of MySQL user to be looking at > PostgreSQL on Win32. Which potentially means lots of FAT32 use. And > yes, even for a "production" environment. Ack! Double-ack! I was just trying to point out the inherent elitist bias in saying that Microsoft's old filesystem should be tested, even though it's use is discouraged, while one of Linux's new filesystems shouldn't, even though it's use is popular. There's a huge double standard here, caused by fear, uncertainty, and doubt. I'm just personally pretty tired of this anti-Microsoft bias. I'm going to be frank and say that many of the people here sound like a bunch of elitist assholes who refuse to sully themselves with a well-used, well-supported, and lately very useful operating system. For those of you who know my history (or care), I've supported Solaris, Linux, Win NT from 3.51 on up, and worked at one of the non-Linux "anti-Microsoft" companies for 4 years. I worked in a testlab where we tested and broke NT (usually caused by driver failures), SCO Unix (who KNOWs what made it panic), and Netware (effectively bulletproof). The fact is, the Win32 platform is mature. It is a modern operating system, and just because they don't do some things the way that the old guard Unix greybeards to doesn't necessarily make it inferior. What's more, all of this testing of filesystems is pretty moot at some point. So far, I've lost more data and time due to a bad locking procedure during vacuums (forcing a lot of quiet in-field upgrades from 7.2.2 to 7.2.3) then I ever expect to lose due to power failure. If we could spend a little more time testing the actual product and a little less time worrying about the underlying operating system, I'd be pretty happy. ...and I'm done discussing the issue for now, since there's not much more for me to say... -- Adam Haberlach | "If I have hacked deeper than them, it is [EMAIL PROTECTED] | because I stand in their trenches." http://mediariffic.com |-- Graham Nelson ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 port powerfail testing
On Sat, 2003-02-01 at 00:34, Adam Haberlach wrote: > On Sat, Feb 01, 2003 at 12:27:31AM -0600, Greg Copeland wrote: > > On Fri, 2003-01-31 at 14:36, Dave Page wrote: > > > > > > I intend to run the tests on a Dual PIII 1GHz box, with 1Gb of Non-ECC > > > RAM and a 20Gb (iirc) IDE disk. I will run on Windows 2000 Server with > > > an NTFS filesystem, and again on Slackware Linux 8 with either ext3 or > > > reiserfs (which is preferred?). > > > > > > > Please go with XFS or ext3. There are a number of blessed and horror > > stories which still float around about reiserfs (recent and old; even > > though I've never lost data with it -- using it now even). > > > > Might be worth testing FAT32 on NT as well. Even if we don't advocate > > it's use, it may not hurt to at least get an understanding of what one > > might reasonably expect from it. I'm betting there are people just > > waiting to run with FAT32 in the Win32 world. ;) > > You'd better go with NTFS. There are a number of blessed and horror > stories which still float around about FAT32 (recent and old; even though > I've never lost data with it -- using it now even now. > > Might be worth testing reiserfs on Linux as well. Even if we don't > advocate it's use, it may not hurt to at least get an understanding of > what one my reasonably expect from it. I'm better there are people > just waiting to run with reiserfs in the Linux world. ;) > > Regards, and tongue firmly in cheek, Touche! :P While I understand and even appreciate the humor value, I do believe the picture is slightly different than your "analysis". If we make something that runs on Win32 platforms, might it also run on Win98, WinME, etc.? Let's face the facts that should it also run on these platforms, it's probably only a matter of time before someone has it running on FAT32 (even possible on NT, etc). In other words, I'm fully expecting the lowest common denominator of MySQL user to be looking at PostgreSQL on Win32. Which potentially means lots of FAT32 use. And yes, even for a "production" environment. Ack! Double-ack! Also, Dave was asking for feedback between reiserfs and ext3. I offered XFS and ext3 as candidates. I personally believe that ext3 and XFS are going to be the more common (in that order) of journaled FS for DB Linux users. Besides, aside from any bugs in reiserfs, testing results for ext3 or XFS should probably coincide with reasonable expectations for reiserfs as well. As I consider FAT32 to be much more fragile than ext2 (having had seriously horrendous corruption and repaired/recovered from it on ext2), the results may prove interesting. Which is to say, should testing prove absolutely horrible results, proper disclaimers and warnings should be made readily available to avoid its use. Which is probably not a bad idea to begin with. ;) Nonetheless, it's an unknown right now in my mind. Hopefully some testing my reveal what reasonable expectations we should hold so that we can knowingly advise accordingly. Regards, -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] sync()
Kurt Roeckx wrote: > On Sat, Feb 01, 2003 at 08:15:17AM -0800, Kevin Brown wrote: > > Kurt Roeckx wrote: > > > [SIO] [Option Start] If _POSIX_SYNCHRONIZED_IO is defined, the > > > fsync() function shall force all currently queued I/O operations > > > associated with the file indicated by file descriptor fildes to the > > > synchronized I/O completion state. All I/O operations shall be > > > completed as defined for synchronized I/O file integrity > > > completion. [Option End] > > > > Hmmmso if I consistently want these semantics out of fsync() I > > have to #define _POSIX_SYNCHRONIZED_IO? Or does the above mean that > > you'll get those semantics if and only if the OS defines the above for > > you? > > It's something that will be defined in unistd.h. Depending on > the value you know if the system supports it always, you can turn > it on per application, or it's always on. > > You know that this standard is freely available on internet? > (http://www.unix-systems.org/version3/online.html) > > There are other comments in about the usage of it. > > Note that there also is a function call fdatasync() in the > Synchronized IO extention. Ah, excellent, thank you. Yes, fdatasync() is *exactly* what we need, since it's defined thusly: "The functionality shall be equivalent to fsync() with the symbol _POSIX_SYNCHRONIZED_IO defined, with the exception that all I/O operations shall be completed as defined for synchronized I/O data integrity completion". Looks to me like we have a winner. Question is, can we bank on its existence and, if so, is it properly implemented on all platforms that support it? Since we've been talking about porting to rather different platforms (win32 in particular), it seems logical to build a PGFileSync() function or something (perhaps a single PGSync() which synchronizes all relevant PG files to disk, with sync() if necessary) and which would thus use fdatasync() or its equivalent. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] On file locking
Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > > So if we wanted to make use of mandatory locks, we'd have to refrain > > from using flock(). > > We have no need for mandatory locks; the advisory style will do fine. > This is true because we have no desire to interoperate with any > non-Postgres code ... everyone else is supposed to stay the heck out of > $PGDATA. True. But, of course, mandatory locks could be used to *make* everyone else stay out of $PGDATA. :-) -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
On Sat, 2003-02-01 at 00:46, Dann Corbit wrote: > MySQL for Win32 has no connection whatsoever with anything from Cygwin > or Mingw Excellent. Thanks for humoring me. ;) -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PERFORM] not using index for select min(...)
Kevin Brown <[EMAIL PROTECTED]> writes: > Hmm...any chance, then, of giving aggregate functions a means of > asking which table(s) and column(s) the original query referred to so > that it could do proper optimization on its own? You can't usefully do that without altering the aggregate paradigm. It won't help for min() to intuit the answer quickly if the query plan is going to insist on feeding every row to it anyway. > For instance, for a > "SELECT min(x) FROM mytable" query, the min() function would be told > upon asking that it's operating on column x of mytable, whereas it > would be told "undefined" for the column if the query were "SELECT > min(x+y) FROM mytable". In the former case, it would be able to do a > "SELECT x FROM mytable ORDER BY x LIMIT 1" on its own, Don't forget that it would also need to be aware of whether there were any WHERE clauses, joins, GROUP BY, perhaps other things I'm not thinking of. In the end, the only reasonable way to handle this kind of thing is to teach the query planner about it. Considering the small number of cases that are usefully optimizable (basically only MIN and MAX on a single table without any WHERE or GROUP clauses), and the ready availability of a SQL-level workaround, it strikes me as a very low-priority TODO item. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] On file locking
Kevin Brown <[EMAIL PROTECTED]> writes: > So if we wanted to make use of mandatory locks, we'd have to refrain > from using flock(). We have no need for mandatory locks; the advisory style will do fine. This is true because we have no desire to interoperate with any non-Postgres code ... everyone else is supposed to stay the heck out of $PGDATA. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] sync()
On Sat, Feb 01, 2003 at 08:15:17AM -0800, Kevin Brown wrote: > Kurt Roeckx wrote: > > [SIO] [Option Start] If _POSIX_SYNCHRONIZED_IO is defined, the > > fsync() function shall force all currently queued I/O operations > > associated with the file indicated by file descriptor fildes to the > > synchronized I/O completion state. All I/O operations shall be > > completed as defined for synchronized I/O file integrity > > completion. [Option End] > > Hmmmso if I consistently want these semantics out of fsync() I > have to #define _POSIX_SYNCHRONIZED_IO? Or does the above mean that > you'll get those semantics if and only if the OS defines the above for > you? It's something that will be defined in unistd.h. Depending on the value you know if the system supports it always, you can turn it on per application, or it's always on. You know that this standard is freely available on internet? (http://www.unix-systems.org/version3/online.html) There are other comments in about the usage of it. Note that there also is a function call fdatasync() in the Synchronized IO extention. Kurt ---(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] POSIX regex performance bug in 7.3 Vs. 7.2
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > Why on earth are you using a CVS version!?!?!?! I assume he meant tip of REL7_3 branch --- which is a perfectly reasonable thing to install, even if there are still a few fixes to go before we call it 7.3.2. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PERFORM] not using index for select min(...)
Tom Lane wrote: > Sean Chittenden <[EMAIL PROTECTED]> writes: > > Now, there are some obvious problems: > > You missed the real reason why this will never happen: it completely > kills any prospect of concurrent updates. If transaction A has issued > an update on some row, and gone and modified the relevant aggregate > cache entries, what happens when transaction B wants to update another > row? It has to wait for A to commit or not, so it knows whether to > believe A's changes to the aggregate cache entries. > > For some aggregates you could imagine an 'undo' operator to allow > A's updates to be retroactively removed even after B has applied its > changes. But that doesn't work very well in general. And in any case, > you'd have to provide serialization interlocks on physical access to > each of the aggregate cache entries. That bottleneck applied to every > update would be likely to negate any possible benefit from using the > cached values. Hmm...any chance, then, of giving aggregate functions a means of asking which table(s) and column(s) the original query referred to so that it could do proper optimization on its own? For instance, for a "SELECT min(x) FROM mytable" query, the min() function would be told upon asking that it's operating on column x of mytable, whereas it would be told "undefined" for the column if the query were "SELECT min(x+y) FROM mytable". In the former case, it would be able to do a "SELECT x FROM mytable ORDER BY x LIMIT 1" on its own, whereas in the latter it would have no choice but to fetch the data to do its calculation via the normal means. But that may be more trouble than it's worth, if aggregate functions aren't responsible for retrieving the values they're supposed to base their computations on, or if it's not possible to get the system to refrain from prefetching data for the aggregate function until the function asks for it. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] On file locking
Curt Sampson wrote: > On Fri, 31 Jan 2003, Shridhar Daithankar<[EMAIL PROTECTED]> wrote: > > > Besides file locking is implemented using setgid bit on most unices. And > > everybody is free to do what he/she thinks right with it. > > I don't believe it's implemented with the setgid bit on most Unices. As > I recall, it's certainly not on Xenix, SCO Unix, any of the BSDs, Linux, > SunOS, Solaris, and Tru64 Unix. > > (I'm talking about the flock system call, here.) Linux, at least, supports mandatory file locks. The Linux kernel documentation mentions that you're supposed to use fcntl() or lockf() (the latter being a library wrapper around the former) to actually lock the file but, when those operations are applied to a file that has the setgid bit set but without the group execute bit set, the kernel enforces it as a mandatory lock. That means that operations like open(), read(), and write() initiated by other processes on the same file will block (or return EAGAIN, if O_NONBLOCK was used to open it) if that's what the lock on the file calls for. That same documentation mentions that locks acquired using flock() will *not* invoke the mandatory lock semantics even if on a file marked for it, so I guess flock() isn't implemented on top of fcntl() in Linux. So if we wanted to make use of mandatory locks, we'd have to refrain from using flock(). -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] pg_dump is broken by recent privileges changes
In CVS tip, create an empty database. pg_dump it. Try to restore the
dump. The first thing it does is
REVOKE ALL ON SCHEMA public FROM PUBLIC;
which fails with
ERROR: dependent privileges exist (use CASCADE to revoke them too)
This message seems incorrect --- what is a dependent privilege, and
why would PUBLIC have any? All I see in pg_namespace is
public |1 | {=UC/postgres}
Also, pg_dump itself seems confused --- the full text of a dump from
an empty DB is (omitting comment lines)
\connect - postgres
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT ALL ON SCHEMA public TO PUBLIC;
GRANT ALL ON SCHEMA public TO PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
which is not only inefficient but wrong, since public surely should
have privileges when the dust settles.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] sync()
Kurt Roeckx wrote: > [SIO] [Option Start] If _POSIX_SYNCHRONIZED_IO is defined, the > fsync() function shall force all currently queued I/O operations > associated with the file indicated by file descriptor fildes to the > synchronized I/O completion state. All I/O operations shall be > completed as defined for synchronized I/O file integrity > completion. [Option End] Hmmmso if I consistently want these semantics out of fsync() I have to #define _POSIX_SYNCHRONIZED_IO? Or does the above mean that you'll get those semantics if and only if the OS defines the above for you? I certainly hope the former is the case, because the newer semantics which you mentioned in the section I cut don't do us any good at all and we can't rely on the OS to define something like _POSIX_SYNCHRONIZED_IO for us... Being able to open a file, do an fsync(), and have the kernel actually write all the buffers associated with that file to disk could be, I think, a significant performance win compared with the "flush everything known to the kernel" approach we take now, at least on systems that do something other than PostgreSQL... -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [mail] Re: [HACKERS] Windows Build System
I think I have sorted through the confusion. Looks like the only thing cygwin might be used for is a client. Here's what the manual that comes with the 4.0.9gamma source says: There are two versions of the MySQL command-line tool: Binary Description mysql Compiled on native Windows, which offers very limited text editing capabilities. mysqlc Compiled with the Cygnus GNU compiler and libraries, which offers readline editing. If you want to use mysqlc.exe, you must copy `C:\mysql\lib\cygwinb19.dll' to your Windows system directory (`\windows\system' or similar place). I don't see a msqlc.exe below, but it is in the released binary distribution, along with the cygwinb19.dll. (kinda strange having a mismatch between source and binary distributions). The server appears to be entirely native. andrew - Original Message - From: "Dann Corbit" <[EMAIL PROTECTED]> To: "Christopher Browne" <[EMAIL PROTECTED]>; "Greg Copeland" <[EMAIL PROTECTED]> Cc: "Justin Clift" <[EMAIL PROTECTED]>; "Jeff Davis" <[EMAIL PROTECTED]>; "PostgresSQL Hackers Mailing List" <[EMAIL PROTECTED]> Sent: Friday, January 31, 2003 8:22 PM Subject: Re: [mail] Re: [HACKERS] Windows Build System > For MySQL: > There is no Cygwin needed. Period. > > I did a build last night. Using nothing but Visual Studio with the > Intel C++ compiler for Win32. > Here is what got built: > E:\mysql-3.23.55>dir /s *.dll, *.exe > Volume in drive E has no label. > Volume Serial Number is 7496-C335 > > Directory of E:\mysql-3.23.55\client_debug > > 31/01/03 11:36a 557,115 isamchk.exe > 31/01/03 11:37a 733,247 myisamchk.exe > 31/01/03 11:37a 602,175 myisamlog.exe > 31/01/03 11:37a 487,480 mysql.exe > 31/01/03 11:37a 458,813 mysqladmin.exe > 31/01/03 11:37a 479,299 mysqlbinlog.exe > 31/01/03 11:38a 4,296,758 mysqld.exe > 31/01/03 11:37a 598,076 mysqldump.exe > 31/01/03 11:37a 446,526 mysqlimport.exe > 31/01/03 11:37a 573,500 mysqlshow.exe > 31/01/03 12:48a45,056 mysqlshutdown.exe > 31/01/03 11:38a 618,559 pack_isam.exe > 31/01/03 11:38a 307,200 replace.exe > 13 File(s) 10,203,804 bytes > > Directory of E:\mysql-3.23.55\client_release > > 31/01/03 11:36a 327,680 isamchk.exe > 31/01/03 11:37a 458,752 myisamchk.exe > 31/01/03 11:37a 372,736 myisamlog.exe > 31/01/03 11:37a 323,642 mysql.exe > 31/01/03 11:37a 274,432 mysqladmin.exe > 31/01/03 11:37a 278,528 mysqlbinlog.exe > 31/01/03 11:37a 270,336 mysqlcheck.exe > 31/01/03 12:35a 3,002,368 mysqld-max-nt.exe > 31/01/03 12:48a 2,994,176 mysqld-max.exe > 31/01/03 11:38a 2,564,096 mysqld-nt.exe > 31/01/03 11:37a 2,560,000 mysqld-opt.exe > 31/01/03 11:37a 286,720 mysqldump.exe > 31/01/03 11:37a 266,240 mysqlimport.exe > 31/01/03 11:37a 270,336 mysqlshow.exe > 31/01/03 12:48a45,056 mysqlshutdown.exe > 31/01/03 12:48a49,152 mysqlwatch.exe > 31/01/03 11:38a 274,432 pack_isam.exe > 31/01/03 11:38a 167,936 perror.exe > 31/01/03 11:37a 188,416 replace.exe > 19 File(s) 14,975,034 bytes > > Directory of E:\mysql-3.23.55\COMP_ERR\Release > > 31/01/03 11:36a 167,936 comp-err.exe >1 File(s)167,936 bytes > > Directory of E:\mysql-3.23.55\libmysqltest\debug > > 31/01/03 11:37a 122,943 myTest.exe >1 File(s)122,943 bytes > > Directory of E:\mysql-3.23.55\libmysqltest\release > > 31/01/03 11:37a49,152 myTest.exe >1 File(s) 49,152 bytes > > Directory of E:\mysql-3.23.55\lib_debug > > 31/01/03 11:37a 467,005 libmySQL.dll >1 File(s)467,005 bytes > > Directory of E:\mysql-3.23.55\lib_release > > 31/01/03 11:36a 278,528 libmySQL.dll >1 File(s)278,528 bytes > > Directory of E:\mysql-3.23.55\myisampack\debug > > 31/01/03 11:37a 553,025 myisampack.exe >1 File(s)553,025 bytes > > Directory of E:\mysql-3.23.55\myisampack\release > > 31/01/03 11:37a 311,296 myisampack.exe >1 File(s)311,296 bytes > > Directory of E:\mysql-3.23.55\my_print_defaults\Debug > > 31/01/03 11:37a 319,567 my_print_defaults.exe >1 File(s)319,567 bytes > > Directory of E:\mysql-3.23.55\my_print_defaults\Release > > 31/01/03 11:37a 180,224 my_print_defaults.exe >1 File(s)180,224 bytes > > Directory of E:\mysql-3.23.55\PERROR\Debug > > 31/01/03 11:38a
Re: [HACKERS] Windows Build System - who cares?
> IMHO, replication, performance improvements, cross-db queries, etc is > much better use of time than Windows port. Because you don't use Windows. On a personal level, I couldn't agree more. But I have been in a project where they chose MySQL because it had to run on Windows. I would like to be able to propose a free alternative. -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 port powerfail testing
Try it with FreeBSD's UFS and FreeBSD 5.0's new UFS2 filesystems perhaps - or I could! Chris On 1 Feb 2003, Greg Copeland wrote: > On Fri, 2003-01-31 at 14:36, Dave Page wrote: > > > > I intend to run the tests on a Dual PIII 1GHz box, with 1Gb of Non-ECC > > RAM and a 20Gb (iirc) IDE disk. I will run on Windows 2000 Server with > > an NTFS filesystem, and again on Slackware Linux 8 with either ext3 or > > reiserfs (which is preferred?). > > > > Please go with XFS or ext3. There are a number of blessed and horror > stories which still float around about reiserfs (recent and old; even > though I've never lost data with it -- using it now even). > > Might be worth testing FAT32 on NT as well. Even if we don't advocate > it's use, it may not hurt to at least get an understanding of what one > might reasonably expect from it. I'm betting there are people just > waiting to run with FAT32 in the Win32 world. ;) > > > Regards, > > -- > Greg Copeland <[EMAIL PROTECTED]> > Copeland Computer Consulting > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Linux.conf.au 2003 Report
On Fri, Jan 31, 2003 at 06:51:49PM -0500, Andrew Sullivan wrote: > On Fri, Jan 31, 2003 at 08:21:21PM +0100, Kurt Roeckx wrote: > > What do you mean with "compatibility addresses"? I don't know of > > any such thing. > > | 96-bits | 32-bits| > +--+--+ > |0:0:0:0:0:0 | IPv4 Address | > +--+--+ >IPv4-Compatible IPv6 Address Format Oh, those. I forgot about them. I've never seen anybody using them, and I can't think of a good reason to use them either. They're not even routable now. Kurt ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
Why on earth are you using a CVS version!?!?!?! Chris On Fri, 31 Jan 2003, wade wrote: > Hello, > We recently upgraded a project from 7.2 to 7.3.1 to make use of some of > the cool new features in 7.3. The installed version is CVS stable from > yesterday. However, we noticed a major performance hit in POSIX regular > expression matches against columns using the ~* operator. > http://arch.wavefire.com/badregex73.txt has explain analyze output from 7.2 > and 7.3.1 respectively. Both of these tables have only 101 rows. The > 7.3.1 install is using the default settings from postgresql.conf. > > Any ideas as to why this should be happening? > > Should anyone require additional information, please let me know. > > -Wade Klaver > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [OpenFTS-general] relor and relkov
I'll volunteer to do some docs... Chris On Fri, 31 Jan 2003, Oleg Bartunov wrote: > Hi there, > > we've discussed with Teodor about adding ranking feature to tsearch and > seems we've found a way to do that. New version of tsearch will have > ranking supports, friendly configurability, linguistic options > and removing some internal limits. Expect alpha-version in 1-2 weeks. > But, we need help to create good documentation for tsearch ! > This is main stopper for releasing of tsearch. > > Oleg > On Wed, 29 Jan 2003, Uros Gruber wrote: > > > Hi, > > > > about this problem i was talking about. With openFTS you're > > forced to use those two fields. If you wan't to use other > > columns you can, becase of those 2 functions. > > > > I make someking workaround and concatenate all columns and > > index this. But then you can't change weight for each column. > > > > Because of this i think that we have to work more on this > > tsearch and ranking and make this more close to postgresql. > > > > > > > > Regards, > Oleg > _ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Windows Build System - My final thoughts
On Saturday 01 February 2003 01:26, Lamar Owen wrote: > On Friday 31 January 2003 03:21, Bruce Momjian wrote: > > Man, I go away for one day, and look what you guys get into. :-) > > No duh. Whew. > > > Lastly, SRA just released _today_ their first Win32 port of PostgreSQL, > > and it is _threaded_: > > > > http://osb.sra.co.jp/PowerGres/ > > Is there an English translation of the site so one who doesn't speak or > write Japanese can try it out? Can't see one, but here is a summarized translation of the relevant parts as I understand them. HTH Ian Barwick [EMAIL PROTECTED] http://osb.sra.co.jp/PowerGres/ --- "Announcement about Powergres" * Release of [ Beta download ] of PowerGres (31.1.2003) * [Press release] (27.11.2002) http://osb.sra.co.jp/PowerGres/introduction.php --- "PowerGres (PostgreSQL on Windows)" "The standard open source database 'PostgreSQL' on Windows" PowerGres is a DBMS which has been developed on the basis of PostgreSQL and ported to Windows (2000 / XP). PowerGres' features: Port of Postgres to Windows The popular Unix/Linux OS Database "postgresql" becomes more accessible Optimised for the Windows environment A thread model enabling effective processing of multiple transactions is used. This enables maximum performance in a windows environment. Web back end DB at low cost There is no limit to the number of users who can connect concurrently, making (PowerGres) suitable as a low cost web app backend DB GUI admin tool A GUI admin tool is packaged with powergres. This enables beginners to perform database management visually / per point and click Japanese manual provided (translation of original Postgres manuals) C, Java Interface spport API for C and Java provided (pretty pictures, presumably of GUI admin tool) http://osb.sra.co.jp/PowerGres/function.php === "Table of PowerGres functions" (comparision with "other DBs for windows", seems a bit pointless, left out) http://osb.sra.co.jp/PowerGres/catalog.php == "Product catalogue" (more: overview) Environment: CPU: Pentiium or compat, min 300Mhz OS: Windows 2000 (SP2 or later), XP Memory: 128MB (rec: 256MB +) Drive space: 100MB+ Product: - 1 CD ROM - PowerGres installer - PowerGres . PowerGres GUI admin tol - PostgreSQL 7.3 Japanese documentation - also: - PowerGres handbook - user registration - misc Installation support Free support by email and fax for 30 days after registration Price 48,000 Yen + tax (probably 5% sales tax; we're talking roughly total US$ 500 or about the same in Euros) Available from March 2003 (scheduled) Beta download available from Jan 2003 http://powergres.sra.co.jp/ === (Beta dowload) Thankyou for your interest in PowerGres. A free beta version of PowerGres is available. Currently 1.0b s available for download. It can be evaluated for 30 days. Please do not hesitate to try before you buy. We cannot offer any support for this software. Use at own risk (blah blah). Also , be aware the Beta version has some restrictions / lack of features compared to the release version, see here: http://osb.sra.co.jp/PowerGres/beta_restriction.php (list of things, mainly command line tools with certain options not working properly) DOWNLOAD FORM: Name* Email* Company Dept. Postal code* Address* * required. (Note: Japanese postal code are like 111- ). ( There follows a select box clicked by default enabling SRA to send you emails... The button is "Send".) (following that, privacy info boilerplate). http://osb.sra.co.jp/PowerGres/faq.php == (not a complete translation, only the interesting points from this page) "FAQ" - License: one license per server; client software is unrestricted ,though no free support available. - it is possible to transfer data from a PostgreSQL installation to PowerGres, though some restrictions apply; - restrictions are among others: - max simultaneous connections 50 users (seems to contradict a previous statement...) - User-definable functions only in C, SQL, PL/pgSQL - No UNIX domain socket support - authentication only trust/reject/md5 ---(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
