Re: [mail] Re: [HACKERS] Windows Build System
Jeff Davis wrote: What about it? Someone claimed in this thread that MySQL's Windows port requires Cygwin. Is that true or not? It's been a while, but I know I've installed MySQL on windows without any separate step of installing Cygwin (I can't say 100% for sure that it didn't install some part of Cygwin transparently to me). From the MySQL site's page about MySQL vs PostgreSQL: http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html MySQL Server works better on Windows than PostgreSQL does. MySQL Server runs as a native Windows application (a service on NT/2000/XP), while PostgreSQL is run under the Cygwin emulation. That seems pretty straightforward. Regards and best wishes, Justin Clift Regards, Jeff Davis -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Windows Build System - My final thoughts
On Thu, 2003-01-30 at 16:01, Vince Vielhaber wrote: Dave, Lamar and Katie can cheer now 'cuze this is the last comment I'm going to make on this. All others will be ignored, probably. The one thing I haven't seen from Dave, Lamar or Katie on this is reputation. You're all for the PostgreSQL name going on it but I have yet to see any of you so sure of yourselves that you'd put your own name on it. The license allows it. Red Hat did it. I see no PageSQL or KatieSQL or even an Oh-Win SQL being offered up. Yet all three of you are advocating that the PostgreSQL stamp of approval should be immediately placed on it (ok, Lamar may not be as in favor as the Dave and Katie). Oh-win SQL! Man that was great :-) If only all of your posts were so witty... Without documented testing and sufficient warnings until enough history is banked, I don't think a native windows port should be given any kind of seal of approval. After that, what about keeping the code current? In a year or so will it suffer from bit-rot and be the source of complaints? Are there going to be security concerns surrounding it? Is there going to be a bunch of scrambling going on to put out a patch when the latest active-x bug hoses the data dir? We already support postgresql on cygwin, and we know that's crap. Having a native emulation can only improve that situation, so I don't see any reason not to move in that direction. All of this stamp of approval talk is really pointless at this juncture; no matter how much testing has been done, none of it means a lick until the code is integrated into the 7.4 branch. In the mean time, if some of the unix oriented guys want to devise a suggested test plan that can be used to determine if we are going to call the native windows support production grade or merely a vast improvement over the cygwin developers version, well I bet the windows folks would appreciate that. Even more so if someone runs those tests against a linux box so that we have actual statistics to compare against. Robert Treat ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [mail] Re: [HACKERS] Windows Build System
Jeff Davis wrote: What about it? Someone claimed in this thread that MySQL's Windows port requires Cygwin. Is that true or not? It's been a while, but I know I've installed MySQL on windows without any separate step of installing Cygwin (I can't say 100% for sure that it didn't install some part of Cygwin transparently to me). That may have involved not being sufficiently observant, because the company quite clearly documents Cygwin as a dependancy. http://www.mysql.com/downloads/cygwin.html -- output = (aa454 @freenet.carleton.ca) http://www3.sympatico.ca/cbbrowne/linuxxian.html Change is inevitable, except from a vending machine. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [mail] Re: [HACKERS] Windows Build System
Jan Wieck wrote: Looking at the arguments so far, nearly everyone who questions the Win32 port must be vehemently against the Cygwin stuff anyway. So that camp should be happy to see it flushed down the toilet. And the pro-Win32 people want the native version because they are unhappy with the stepchild-Cygwin stuff too, so they won't care too much. What is interesting is that the MySQL folk don't seem to be vehemently against it, as a look at their downloads pages indicate that they depend on Cygwin for the Windows port of their product. -- output = (cbbrowne @ntlug.org) http://www.ntlug.org/~cbbrowne/lisp.html What did we agree about a leader?? We agreed we wouldn't have one. Good. Now shut up and do as I say... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Linux.conf.au 2003 Report
On Fri, Jan 31, 2003 at 10:57:17AM +0900, Curt Sampson wrote: Hm? DNS completely separates IPv4 and IPv6 addresses; they're different record types (A versus ) in the DNS database. And the interoperation if IPv4 and IPv6 is pretty much not happening, if you're talking about the compatability addresses. I won't get into all the reasons why. I know it's not happening. On the other hand, IPv6 isn't happening terribly much, either. Soon, the NAT + CIDR bag-on-the-side will run out of room, and people will have no choice but to use IPv6. But the pain of making them interoperate is part of the cause of resistance. The compatibility addresses are going to _have_ to work if people are really going to move, unless someone is contemplating another great TCP/IP cutover day. (And that didn't even work last time, when several networks just dropped right off the proto-Net for a while.) So it seems to me that the compatibility addresses are going to need to be supported by any IPv6-aware system. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] On file locking
But this only wins if a child process inheriting an open file also inherits copies of any locks held by the parent. If not, then the issue is moot. Anybody have any idea if file locks work that way? Is it portable?? From RedHat 8.0 manages fork(2): SYNOPSIS #include sys/types.h #include unistd.h pid_t fork(void); DESCRIPTION fork creates a child process that differs from the parent process only in its PID and PPID, and in the fact that resource utilizations are set to 0. File locks and pending signals are not inherited. ^^ ^^ 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. If I understand correctly it says that if parent dies, file is unlocked no matter if there's children still running? -- Antti Haapala ---(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
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. If the fork results in multiple references to the open file, then I should think that if the parent dies but the child still holds the file open, then the lock still exists. Seems that some experimentation is called for ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [mail] Re: [HACKERS] Windows Build System
Christopher Browne wrote: snip From the MySQL site's page about MySQL vs PostgreSQL: http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html MySQL Server works better on Windows than PostgreSQL does. MySQL Server runs as a native Windows application (a service on NT/2000/XP), while PostgreSQL is run under the Cygwin emulation. That seems pretty straightforward. But it's not /nearly/ that straightforward. If you look at the downloads that MySQL AB provides, they point you to a link that says Windows binaries use the Cygwin library. Which apparently means that this feature is not actually a feature. Unlike PostgreSQL, which is run under the Cygwin emulation, MySQL runs as a native Windows application (with Cygwin emulation). Apparently those are not at all the same thing, even though they are both using Cygwin... Hmm... wonder if they're meaning that MySQL compiles and executes as a True native windows application (skipping any unix compatibility calls), and it's just some of the support utils that use cygwin, or if they're trying to say that PostgreSQL has to operate entirely in the cygwin environment, whereas they don't? Regards and best wishes, Justin Clift -- 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 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
On Fri, 2003-01-31 at 07:22, Christopher Browne wrote: But it's not /nearly/ that straightforward. If you look at the downloads that MySQL AB provides, they point you to a link that says Windows binaries use the Cygwin library. Which apparently means that this feature is not actually a feature. Unlike PostgreSQL, which is run under the Cygwin emulation, MySQL runs as a native Windows application (with Cygwin emulation). Apparently those are not at all the same thing, even though they are both using Cygwin... I'm confused as to whether you are being sarcastic or truly seem to think there is a distinction here. Simple question, does MySQL require the cygwin dll's (or statically linked to) to run? If the answer is yes, then there is little question that they are as emulated as is the current PostgreSQL/Win32 effort. Care to expand on exactly what you believe the distinction is? ...or did I miss the humor boat? :( Regards, -- 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
[HACKERS] Just a test, only a test ...
So ignore it, eh? ---(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] Linux.conf.au 2003 Report
On Fri, Jan 31, 2003 at 09:13:18AM -0500, Andrew Sullivan wrote: Soon, the NAT + CIDR bag-on-the-side will run out of room, and people will have no choice but to use IPv6. But the pain of making them interoperate is part of the cause of resistance. The compatibility addresses are going to _have_ to work if people are really going to move, unless someone is contemplating another great TCP/IP cutover day. What do you mean with compatibility addresses? I don't know of any such thing. The ipv4 mapped ipv6 address is just a hack on the local system. You never see those on the wire. Anyway, what is the problem? ipv4 and ipv6 can happely live on the same network, it does so far a long time now. Host just support both ipv4 and ipv6 now. If an application is written properly, you shouldn't even notice the connection is over ipv4 or ipv6. Kurt ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] type problems during union: NULL+NULL produces TEXT
Hi, I have three tables, two of which are missing a column: CREATE TABLE table1 (t1 TEXT); CREATE TABLE table2 (t2 TEXT); CREATE TABLE table3 (t3 TEXT, i3 INTEGER); I am trying to create a view over these tables that defaults values for non-existant columns to NULL. CREATE VIEW view1 (i, t) AS SELECT t1, NULL FROM table1 UNION ALL SELECT t2, NULL FROM table2 UNION ALL SELECT t3, i3 FROM table3 ; This fails with ERROR: UNION types 'text' and 'integer' not matched suggesting that NULL+NULL produces TEXT as type of the second column in the union. The plain select (without CREATE VIEW) fails in the same way. It works for two tables (NULL+INTEGER = INTEGER): CREATE VIEW view2 (i, t) AS SELECT t1, NULL FROM table1 UNION ALL SELECT t3, i3 FROM table3 ; and of course with explicit casts CREATE VIEW view3 (i, t) AS SELECT t1, NULL::integer FROM table1 UNION ALL SELECT t2, NULL::integer FROM table2 UNION ALL SELECT t3, i3 FROM table3 ; Best wishes, Mike PS: This is version() 'PostgreSQL 7.3.1 on i686-pc-linux-gnu, compiled by GCC 2.95.4'. -- Life is like a fire. DI Michael Wildpaner Flames which the passer-by forgets. Ph.D. Student Ashes which the wind scatters. A man lived. -- Omar Khayyam ---(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] Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 08:21:09PM -0600, Greg Copeland wrote: IPv6 has some provisions to help people migrate toward it (from IPv4), however, IPv6 is a distinctly different protocol. The ipv4 mapped ipv6 addresses are to help migrate, but it actually makes things worse. If this wouldn't be the case, some software wouldn't look as ugly as it does now. Then there is the problem that BSD no longer really supports the ipv4 mapped ipv6 addresses. It will refuse to use such an address on an AF_INET6 socket, while that (still) works on other OSs. The badly ported software will not work on them. It doesn't help the confusion that many OS's try to confuse programmers by exposing a single socket interface, etc. Simple fact remains, IPv6 is not IPv4. 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. The new protocol independed API for translation between host name and address, in both text and binary representation is also a good thing. The struct addrinfo is really useful, since you can store all info you need in it for all calls to the socket API. The ipv6 patch really should make better use of it, both if you have and don't have ipv6 support, and get rid of most of those #ifdefs. Kurt ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 08:13:30PM -0500, Tom Lane wrote: Kurt Roeckx [EMAIL PROTECTED] writes: On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote: We have to work out what the semantics should be. I don't know anything about v6, but I'd imagine v4 addresses form a defined subset of the v6 address space ... if so the semantics seem pretty straightforward. You have a ipv4 mapped ipv6 address. The ipv4 address 1.2.3.4 becomes :::1.2.3.4. But I'm not really in favour of automatically changing an ipv4 address to an ipv6 address. And you really shouldn't return an ipv4 address as an ipv6 address. No, we should keep the distinction for purposes of storage and display. The question was about what the semantics should be when comparing v4 and v6 addresses in operations like network_sub. It seems perfectly reasonable to convert the v4 address to the mapped v6 equivalent and then do a v6 comparison in that situation. Do we have any operators where this would not be a sensible definition? broadcast() doesn't make sense for ipv6. There is no such thing. network() might be useful, but mean something a little bit different. Ipv6 calls the mask length the prefix length ... abbrev() might also need some tweaking, specially in combination with the compressed format. Not sure if abbrev() is really useful. There seems to be no documentation on network_sub, but I assume it's the same as . It shouldn't be a problem converting it to the ipv6 address, and adding 96 to the mask. 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: [mail] Re: [HACKERS] Windows Build System
Christopher Browne wrote: snip From the MySQL site's page about MySQL vs PostgreSQL: http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html MySQL Server works better on Windows than PostgreSQL does. MySQL Server runs as a native Windows application (a service on NT/2000/XP), while PostgreSQL is run under the Cygwin emulation. That seems pretty straightforward. But it's not /nearly/ that straightforward. If you look at the downloads that MySQL AB provides, they point you to a link that says Windows binaries use the Cygwin library. Which apparently means that this feature is not actually a feature. Unlike PostgreSQL, which is run under the Cygwin emulation, MySQL runs as a native Windows application (with Cygwin emulation). Apparently those are not at all the same thing, even though they are both using Cygwin... Justin Clift replied: Hmm... wonder if they're meaning that MySQL compiles and executes as a True native windows application (skipping any unix compatibility calls), and it's just some of the support utils that use cygwin, or if they're trying to say that PostgreSQL has to operate entirely in the cygwin environment, whereas they don't? I just downloaded the latest productin source (3.3.55) and it appears to me that: 1) It uses Cygwin emulation via a dll. 2) It uses Visual Studio C++ 6.0 for the primary build environment. It compiles out of the box without having to learn Unix-style build systems, config, make, etc. No warnings, no errors, it just builds out of the box. If I did not have a lot of experience building databases I certainly would have found their support for Windows compelling. This is a big reason why they are #1. 3) The statement by the MySQL folks above that MySQL runs as a native Windows application (a service on NT/2000/XP) is indicative of why MySQL is kicking PostgreSQL's butt in terms of popularity. It is marketing speak at its best. It is technically true, MySQL runs as a service. As Christopher Browne points out, they still use the Cygwin Emulation layer. The statement is misleading, however, as it implies that they don't use any emulation but they do. The salient points: 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. b) MySQL recognizes that the important issue is to appear to be a well supported Windows application rather than to actually be one. c) It is probably much easier to add the support for running as an NT service than it is to write a true native port with no Cygwin dependency. NT Service support is basically a single funtion wrapper for certain API calls (startup, shutdown, etc.) that enable the Windows administration tools to deal with all servers in a similar manner. They have worked on that which makes them look better, makes their prospective customers happier, and makes it easier to support. Exactly what any good product development organization that listens to their customers would have done. flame on IMHO, PostgreSQL will never have the same level of use in the field as MySQL currently does as long as there is the kind head in the sand attitude about Windows that I've seen here on the hackers list, especially as evidenced by the recent outright attacks against those who are simply trying to port PostgreSQL to the largest platform out there today. There have been some very legitimate points about Windows being a new platform, one that will likely see a lot of users, and therefore one that should be more thoroughly tested before release than the typical port to another flavor of *nix. However, the way the conversation started reminds me of some of the chat discussions I've seen between young teens. I was a Mac developer way, way back and long ago realized that the best often loses and that better marketing beats better engineering every single time. \flame off DISCLAIMER: I hate Microsoft and Windows drives me nuts. - Curtis ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [mail] Re: [HACKERS] Windows Build System
- Original Message - From: Greg Copeland [EMAIL PROTECTED] I'm confused as to whether you are being sarcastic or truly seem to think there is a distinction here. Simple question, does MySQL require the cygwin dll's (or statically linked to) to run? If the answer is yes, then there is little question that they are as emulated as is the current PostgreSQL/Win32 effort. Care to expand on exactly what you believe the distinction is? ...or did I miss the humor boat? :( I just installed it (their latest gama), to see what was there (and uninstalled it straight away ;-). There was a cygwinb19.dll (I think that's what it was called) installed. In any case, if we are talking about industrial strength, is this the comparison we should be using? ;-) andrew ---(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] Windows Build System - My final thoughts
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 31, 2003 12:21 AM
To: Lamar Owen
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Windows Build System - My final thoughts
Man, I go away for one day, and look what you guys get into. :-)
Let me shoot out some comments on this.
First, clearly the Win32 port is going to have more
port-specific code paths than any other port, so it is going
to require extra testing even if it wasn't our first non-Unix
port. You can expect it to take some extra effort even after
the port has stabalized because when we add something that
works only on Unix, we will need to code some workaround in Win32.
No question. We had to customize the following files:
backend\access\transam\xlog.c
backend\catalog\aclchk.c
backend\commands\command.c
backend\commands\comment.c
backend\commands\copy.c
backend\commands\creatinh.c
backend\commands\dbcommands.c
backend\commands\define.c
backend\commands\rename.c
backend\commands\user.c
backend\customize\timelib\zic.c
backend\lib\dllist.c
backend\libpq\hba.c
backend\libpq\pqcomm.c
backend\main\main.c
backend\postmaster\pgstat.c
backend\postmaster\postmaster.c
backend\storage\file\fd.c
backend\storage\ipc\ipc.c
backend\storage\smgr\md.c
backend\tcop\utility.c
backend\utils\adt\acl.c
backend\utils\adt\nabstime.c
backend\utils\error\elog.c
backend\utils\fmgr\dfmgr.c
backend\utils\init\findbe.c
backend\utils\init\miscinit.c
backend\utils\misc\guc-file.c
backend\utils\misc\guc.c
backend\utils\misc\superuser.c
bin\pg_dump\common.c
bin\psql\common.c
bin\psql\print.c
bin\psql\startup.c
interfaces\ecpg\preproc\ecpg.c
interfaces\libpgeasy\halt.c
Before each customization, we put:
#ifdef ICKY_WIN32_KLUDGE
{icky fix goes here
#else
{UNIX code goes here}
#endif
Second, there are going to be new error cases on this
platform that we can't anticipate, and some of that isn't
going to show until we get it released. Documenting those
pitfalls, like only using NTFS, is a good start.
It works on FAT32, but you don't have security.
Third, I suspect folks running Win32 aren't as particular
about stability/reliability, or they would have left MS
products already.
Typical Anti-MS rhetoric. That's right. The companies with billions of
dollars at stake don't care about stability or reliability. In fact,
they are stupid. They are using MS products after all. Or (perhaps)
they really are concerned about things like that.
Fourth, some say Win32 isn't an acceptable platform. It may
or may not be for specific people, but Linux may be an
unacceptable platform for some people too. I don't think we
can second guess the users. We will do our best and see how it goes.
Most of the machines in the world run Win32. That's a fact. That may
not be the ideal world, but that's reality.
Also, I have heard from several people that XP is the first
OS MS got right. That may or may not be true, but some feel
things are getting better. It is all a continuim with these
OS's. Some are great, some mediocre, some really bad, but
people make decisions and choose bad ones all the time.
PostgreSQL just needs to be there, if only to migrate them to
a better platform later. If we aren't there, we can't show
them how good we are.
I despise:
Windows 95 (bad)
Windows 98 (bad)
WinME (worst of all) is a bletcherous, buggy hack and not suitable for
any use. It should never have been released.
But I like:
Windows NT
Windows 2000
Windows XP
All are reliable and easy to use.
As for build environment, we have two audiences --- those
using binaries, and those compiling from source. Clearly we
are going to have more binary users vs. source users on Win32
than on any other platform, so at this stage I think making
thing easier for the majority of our Unix developers is the
priority, meaning we should use our existing Makefiles and
cygwin to compile. Later, if things warrant it, we can do
VC++ project files somehow.
MINGW does not require royalties like Cygwin does and emulates the
Windows environments. Perhaps a single, consistent build environment
can be created using MINGW as a basis for Win32 platforms.
Lastly, SRA just released _today_ their first Win32 port of
PostgreSQL, and it is _threaded_:
http://osb.sra.co.jp/PowerGres/
Now, that's a port!
Soulds like it is possible to do then.
Also, when I am back home for an extended period starting in March,
I will going through Jan's patch (if no one does it first) and
submit/apply it in pieces that address specific Win32 issues,
like path names or carriage returns. Once those are in, we can
look at the more complex issues of build handling.
I will be willing to help on the Win32 port
So, as far as I am concerned, we will have a Win32 port in 7.4.
It will not be perfect, but it will be as good as we can do.
We are also getting point-in-time recovery in 7.4, so that may
Re: [HACKERS] Linux.conf.au 2003 Report
On Fri, 2003-01-31 at 13:04, Kurt Roeckx wrote: On Thu, Jan 30, 2003 at 08:21:09PM -0600, Greg Copeland wrote: It doesn't help the confusion that many OS's try to confuse programmers by exposing a single socket interface, etc. Simple fact remains, IPv6 is not IPv4. 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. That's actually not what I was talking about. Please see the recent IPv6 support thread as an example. The fact that an OS allows IPv4 connections to be completed even though you explicitly requested IPv6 protocol, only adds to much confusion (one of many such oddities which some OS's allow). Heck, along those lines, they should allow NCP connections to come through too. Or, how about UDP traffic on TCP sockets. If I wanted IPv4 traffic, I'll ask for it. Likewise of IPv6. My point being, too many people are in a hurry to confuse/combine the two when they are very clearly two distinct protocols, each having distinct needs. The faster people treat them as such, the quicker things will become better for everyone. The fact that some OS's attempt to blur the API lines and underlying semantics between the two protocols only further confuses things as it falsely leads people to believe that they are more or less the same protocol. Regards, -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(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
[Fwd: Re: [mail] Re: [HACKERS] Windows Build System]
Original Message Subject: Re: [mail] Re: [HACKERS] Windows Build System Date: Fri, 31 Jan 2003 15:46:20 -0500 From: mlw [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] CC: Curtis Faith [EMAIL PROTECTED], 'Al Sutton' [EMAIL PROTECTED], 'Bruce Momjian' [EMAIL PROTECTED], [EMAIL PROTECTED] References: 002101c2c625$e3204e30$a200a8c0@curtislaptop [EMAIL PROTECTED] Tom Lane wrote: Curtis Faith writes: If a developer can simply download the source, click on the Visual C++ project in the win32 directory and then build PostgreSQL, and they can see that Windows is not the poor stepchild because the VC project is well laid out, they will be more likely to use it for Windows projects than MySQL which requires the CygWin tools (this means really a Unix product to Windows developers). In all honesty, I do not *want* Windows people to think that they're not running on the poor stepchild platform.If we go down that path, they'll start trying to run production databases on Windows, and then we'll get blamed for the instability of the platform, not to mention the likelihood that it ignores Unix semantics for fsync() and suchlike critical primitives. I have no objection to there being a Windows port that people can use to do SQL-client development on their laptops. But let us please not confuse this with an industrial-strength solution; nor give any level of support that might lead others to make such confusion. The MySQL guys made the right choice here: they don't want to buy into making Windows a grade-A platform, either. OK, I have to weigh in here. I have been a Windows application and kernel driver developer since version 1.0. I have also worked on UNIX since the original Sun machines. Yes, the DOS version of Windows, i.e win95/98/ME is pure unmitigated crap. No doubt. The NT version of Windows, NT/2K/XP has a very well designed kernel. It is more or less based on OpenVMS. To say it is a poor stepchild shows a lack of imagination on your part. The NT lineage of Windows is usable as a production server. I think PostgreSQL using the most pedestrian Win32 API entry points will perform just fine. The core disk I/O subsystem and NTFS are very stable. The scheduler is not great, but is usable. The VM system is probably better than most UNIX environments, including FreeBSD and Linux. The always interruptable always reentrant device driver design could crank out some serious performance on a busy server. That being said, the kernel level GUI of Windows is a dangerous risk. Many of the changes made since the original NT (3.x) do reduce stability in a desktop environment. However, a server environment, such as PG, which does not perform any graphic interactions should be stable enough. If rebooted once a every month or two, the system should never experience data loss and windows admins are used to doing periodic reboots. One last, IMHO very important point, A LOT OF PEOPLE USE WINDOWS! Every effort should be made to support it. Yea, we all have our favorite environments. I choose Linux, others choose a *BSD, some use HPUX, Solaris or whatever. The point is a lot people choose Windows. It is possible to make a stable environment on this platform. Would I choose it? No, but some people do. Don't you think it makes sense to provide a good solution on Windows, and if they run into the inherent limitations of that platform be able to say, Windows has some serious design flaws, but you can upgrade to Solaris or HPUX if you need and getting the user, instead of saying, Windows sucks, use a real platform and losing them? I think it is a AWESOME story to say, Build your app using PG. Start with Windows, if you like, we don't care, if you grow beyond the capabilities of Windows, just upgrade your server, no need to change anything else. Just my $0.02 Mark ---(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 Fri, 2003-01-31 at 07:22, Christopher Browne wrote: But it's not /nearly/ that straightforward. If you look at the downloads that MySQL AB provides, they point you to a link that says Windows binaries use the Cygwin library. Which apparently means that this feature is not actually a feature. Unlike PostgreSQL, which is run under the Cygwin emulation, MySQL runs as a native Windows application (with Cygwin emulation). Apparently those are not at all the same thing, even though they are both using Cygwin... I'm confused as to whether you are being sarcastic or truly seem to think there is a distinction here. Simple question, does MySQL require the cygwin dll's (or statically linked to) to run? I don't know if there's a distinction; read in whatever sarcasm is deserved by the reality of things. If the answer is yes, then there is little question that they are as emulated as is the current PostgreSQL/Win32 effort. Just so. If the answer is yes, then the MySQL folk are claiming an advantage that has no reality to it, in effect, We aren't using Cygwin emulation, so we're better... (Whoops, we're actually /using/ Cygwin emulation.) Care to expand on exactly what you believe the distinction is? ...or did I miss the humor boat? :( I'm making the generous assumption that since /they/ claim that there is some distinction, that there perhaps is one. -- (concatenate 'string cbbrowne @cbbrowne.com) http://cbbrowne.com/info/oses.html All language designers are arrogant. Goes with the territory... -- Larry Wall ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] win32 port --asynchronous I/O and memory
Just a quick question... are you guys using the C runtime or the win32 API to do things like file i/o and memory allocation. If you are using the win32 api, are you using asynchronous I/O? Generally, how much raw win32 code do you expect to write (assumption: as little as possible). As for memory, what's the general allocation scheme? I have not looked at the source much, but I know postgres has a very good memory manager. There are a few different ways of going about it. I wrote a database backend of sorts a while back and my experience was that you have to take certain precautions or you are in danger of thrashing the server, which in extreme cases is basically the same as crashing the system. Part of the danger is memory allocations for the database sometimes compete with the file system caching, causing massive performance degradations. MSSQL avoids this because it is very tightly wound with the virtual allocation system. Merlin ---(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] Linux.conf.au 2003 Report
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. I'm thinking of these sorts of things (my faviourite description, from RFC 2893): IPv6/IPv4 nodes that perform automatic tunneling are assigned IPv4-compatible address. An IPv4-compatible address is identified by an all-zeros 96-bit prefix, and holds an IPv4 address in the low-order 32-bits. IPv4-compatible addresses are structured as follows: | 96-bits | 32-bits| +--+--+ |0:0:0:0:0:0 | IPv4 Address | +--+--+ IPv4-Compatible IPv6 Address Format A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] On file locking
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.) 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: [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.55dir /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 294,969 perror.exe 1 File(s)294,969 bytes Directory of E:\mysql-3.23.55\THR_TEST\debug 31/01/03 11:37a 127,037 thr_test.exe 1 File(s)127,037 bytes Directory of E:\mysql-3.23.55\THR_TEST\release 31/01/03 11:37a53,248 thr_test.exe 1 File(s) 53,248 bytes Total Files Listed: 44 File(s) 28,103,768 bytes 0 Dir(s) 24,246,353,920 bytes free E:\mysql-3.23.55 In the morning, I started the server Daemon (E:\mysql-3.23.55\client_releasemysqld-max-nt.exe in my case). You can connect to it. You can query it. Whatever. No cygwin needed. No Mingw. No nothing. Build in Win32. Run in Win32. It's a pure, native Win32 application. Just so that everyone understands about MySQL -- the [current release] Windows port is definitely, positively a native Win32 application that needs no outside utilities to build, setup, run, or administrate. You can all stop guessing. Now, as far as the Win32 animosity goes, I think that is a natural thing too. There is a culture clash between the Linux camps and the Win32 camps. Typically, it's the highly intelligent kids recently out of college that are in love with Linux, and the [usually older] corporate types that know nothing but Win32. But realize that both sets of people have real problems to solve and
Re: [HACKERS] Windows Build System - My final thoughts
As for build environment, we have two audiences --- those using binaries, and those compiling from source. Clearly we are going to have more binary users vs. source users on Win32 than on any other platform, so at this stage I think making thing easier for the majority of our Unix developers is the priority, meaning we should use our existing Makefiles and cygwin to compile. Later, if things warrant it, we can do VC++ project files somehow. I'm ignorant when it comes to build environments on windows, but I was under the impression that DJGPP was mostly a complete environment. Are there any plans to support it, or is it even possible? So, as far as I am concerned, we will have a Win32 port in 7.4. It will not be perfect, but it will be as good as we can do. We are also getting point-in-time recovery in 7.4, so that may help us with Win32 port failures too. Interesting consolation :) Regards, Jeff Davis ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2
wade [EMAIL PROTECTED] writes: 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. The only thought that comes to mind is that multibyte character sets are supported in 7.3 whereas they were optional (and not default) in 7.2. I'd not have expected a factor-of-150 performance hit from that, though. Could you rebuild your backend with profiling enabled and get a gprof summary of where the time is going? regards, tom lane ---(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 Friday 31 January 2003 20:22, Dann Corbit wrote: Now, as far as the Win32 animosity goes, I think that is a natural thing too. There is a culture clash between the Linux camps and the Win32 camps. Typically, it's the highly intelligent kids recently out of college that are in love with Linux, and the [usually older] corporate types that know nothing but Win32. But realize that both sets of people have real problems to solve and a free, high quality database will be a great help to anyone. :-) The *BSD, Solaris, AIS, HP-UX, IRIX, SCO, and other unixoid partisans out there will just love this statement. The linux community here is in the minority, more than likely, to the *BSD camp. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
mlw [EMAIL PROTECTED] writes: Like it or not, if PG releases a very good Win32 port, ALL the unixoids combined will be out numbered by the windoze users. A lot of us are *not* looking forward to that prospect. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 8:24 PM To: mlw Cc: Lamar Owen; Dann Corbit; PostgresSQL Hackers Mailing List Subject: Re: [mail] Re: [HACKERS] Windows Build System mlw [EMAIL PROTECTED] writes: Like it or not, if PG releases a very good Win32 port, ALL the unixoids combined will be out numbered by the windoze users. A lot of us are *not* looking forward to that prospect. In all seriousness, it may be a good idea to create a special list server group for that exact audience. Call it Win32 PostgreSQL Users or something like that. That way, then can help each other. And the experienced PG users that can stand the noise can pop over to help from time to time. You might have one million PG users in 6 months time. Literally. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [mail] Re: [HACKERS] Windows Build System
Tom Lane wrote: mlw [EMAIL PROTECTED] writes: Like it or not, if PG releases a very good Win32 port, ALL the unixoids combined will be out numbered by the windoze users. A lot of us are *not* looking forward to that prospect. regards, tom lane No doubt to that, but, depending on how good the PG guys are, it is either a blessing or a curse. I think that PG has a REAL chance to be one of THE breakthrough open source technologies. With the exception of OpenOffice, I don't think there is a more important open source project than PG. Simply because SQL databases are a cooperative monopoly. MS, Oracle, and DB2 are like the record companies. They have a cooperative monopoly. Yea, they will seem to compete on price, but none of them really whant to know how low the other will go. Some may argue that Apache or PHP may take second place, but I submit that Apache and PHP are, by and large, much less expensive and much less generic products as an ACID compliant SQL databases. That being said, if a good Win32 port is made, AND it becomes common knkowledge, the use count may square. ---(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
Dann Corbit wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 8:24 PM To: mlw Cc: Lamar Owen; Dann Corbit; PostgresSQL Hackers Mailing List Subject: Re: [mail] Re: [HACKERS] Windows Build System mlw [EMAIL PROTECTED] writes: Like it or not, if PG releases a very good Win32 port, ALL the unixoids combined will be out numbered by the windoze users. A lot of us are *not* looking forward to that prospect. In all seriousness, it may be a good idea to create a special list server group for that exact audience. Call it Win32 PostgreSQL Users or something like that. That way, then can help each other. And the experienced PG users that can stand the noise can pop over to help from time to time. You might have one million PG users in 6 months time. Literally. no doubt ---(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
On Fri, 31 Jan 2003, mlw wrote: Like it or not, if PG releases a very good Win32 port, ALL the unixoids combined will be out numbered by the windoze users. Now that's certainly something to look forward to. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(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 Fri, 2003-01-31 at 19:22, Dann Corbit wrote: For MySQL: There is no Cygwin needed. Period. Any idea as to why we seem to be getting such a conflicting story here? By several accounts, it does. Now, your saying it doesn't. What the heck is going on here. Not that I'm doubting you. I'm just trying to figure out which side of the coin is the shinny one. ;) There's a tool that comes with either the resource kit or the VC++ stuff that will tell you information like what ldd does. I don't recall the name of the tool. Can anyone comment if cygwin (or equivalent) is being linked in (statically or dynamically)? -- 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])
Re: [HACKERS] Windows Build System - who cares?
IMHO, replication, performance improvements, cross-db queries, etc is much better use of time than Windows port. --- Dann Corbit [EMAIL PROTECTED] wrote: For MySQL: There is no Cygwin needed. Period. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ---(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
On Fri, 2003-01-31 at 19:22, Dann Corbit wrote: For MySQL: There is no Cygwin needed. Period. Sorry to followup again, but I did want to point out something. I'm assuming you actually installed it. Please take note that the cygwin dll is normally installed into one of the window's directories (system, windows, etc). My point being, just because you didn't find it in the mysql directory, doesn't mean it wasn't installed system-wide. Not saying it does or doesn't do this. Just offering something else that may need to be looked at. Regards, -- 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] Windows Build System - who cares?
On Fri, Jan 31, 2003 at 22:30:45 -0800, ow [EMAIL PROTECTED] wrote: IMHO, replication, performance improvements, cross-db queries, etc is much better use of time than Windows port. Welcome to open source where individual people get to decide what is most important to spend their time on. ---(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] Linux.conf.au 2003 Report
On Fri, 31 Jan 2003, Andrew Sullivan wrote: But the pain of making them interoperate is part of the cause of resistance. The compatibility addresses are going to _have_ to work if people are really going to move... There is no pain in this respect; you get your compatability by simply running both IPv4 and IPv6 on the hosts that interoperate. 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 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
-Original Message- From: Greg Copeland [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 10:39 PM To: Dann Corbit Cc: Christopher Browne; Justin Clift; Jeff Davis; PostgresSQL Hackers Mailing List Subject: RE: [mail] Re: [HACKERS] Windows Build System On Fri, 2003-01-31 at 19:22, Dann Corbit wrote: For MySQL: There is no Cygwin needed. Period. Sorry to followup again, but I did want to point out something. I'm assuming you actually installed it. After I built it from source code (using Visual Studio with Intel C++), I installed it. Please take note that the cygwin dll is normally installed into one of the window's directories (system, windows, etc). My point being, just because you didn't find it in the mysql directory, doesn't mean it wasn't installed system-wide. MySQL for Win32 has no connection whatsoever with anything from Cygwin or Mingw Not saying it does or doesn't do this. Just offering something else that may need to be looked at. Certainly a good idea. ---(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] Windows Build System - My final thoughts
Man, I go away for one day, and look what you guys get into. :-) Let me shoot out some comments on this. First, clearly the Win32 port is going to have more port-specific code paths than any other port, so it is going to require extra testing even if it wasn't our first non-Unix port. You can expect it to take some extra effort even after the port has stabalized because when we add something that works only on Unix, we will need to code some workaround in Win32. Second, there are going to be new error cases on this platform that we can't anticipate, and some of that isn't going to show until we get it released. Documenting those pitfalls, like only using NTFS, is a good start. Third, I suspect folks running Win32 aren't as particular about stability/reliability, or they would have left MS products already. Fourth, some say Win32 isn't an acceptable platform. It may or may not be for specific people, but Linux may be an unacceptable platform for some people too. I don't think we can second guess the users. We will do our best and see how it goes. Also, I have heard from several people that XP is the first OS MS got right. That may or may not be true, but some feel things are getting better. It is all a continuim with these OS's. Some are great, some mediocre, some really bad, but people make decisions and choose bad ones all the time. PostgreSQL just needs to be there, if only to migrate them to a better platform later. If we aren't there, we can't show them how good we are. As for build environment, we have two audiences --- those using binaries, and those compiling from source. Clearly we are going to have more binary users vs. source users on Win32 than on any other platform, so at this stage I think making thing easier for the majority of our Unix developers is the priority, meaning we should use our existing Makefiles and cygwin to compile. Later, if things warrant it, we can do VC++ project files somehow. Lastly, SRA just released _today_ their first Win32 port of PostgreSQL, and it is _threaded_: http://osb.sra.co.jp/PowerGres/ Now, that's a port! Also, when I am back home for an extended period starting in March, I will going through Jan's patch (if no one does it first) and submit/apply it in pieces that address specific Win32 issues, like path names or carriage returns. Once those are in, we can look at the more complex issues of build handling. So, as far as I am concerned, we will have a Win32 port in 7.4. It will not be perfect, but it will be as good as we can do. We are also getting point-in-time recovery in 7.4, so that may help us with Win32 port failures too. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [mail] Re: [HACKERS] Windows Build System
-Original Message- From: Greg Copeland [mailto:[EMAIL PROTECTED]] Sent: 30 January 2003 22:47 To: Dave Page Cc: Tom Lane; PostgresSQL Hackers Mailing List Subject: Re: [mail] Re: [HACKERS] Windows Build System I have lost entire directory trees (and all associated data) on NTFS before. NTFS was kind enough to detect an inconsistency during boot and repaired the file system by simply removing any and all references to the top level damaged directory (on down). Sure, the file system was in a known good state following the repair but the 2-days to recover from it, pretty much stunk! Don't get me wrong, I'm not saying it doesn't go toes up, just that in my experience (going back the NT3.1) it's not a daily occurance. You also compared NTFS with ext2. That's not exactly fair. Better you should compare NTFS with ext3, XFS, JFS, ReiserFS. It's a better, more fair comparison, as now we're talking about the same category of file system. I realise the differences, but I don't currently use ext3, xfs, jfs or reiserfs on any of my production boxes so can't make any observations about them. I did, less than a month ago, lose and entire pg data directory on an ext2 partition though :-( Regards, Dave. ---(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
On Thu, 2003-01-30 at 20:29, Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
While I understand (and agree with) your (and Vince's) reasoning on why
Windows should be considered less reliable, neither of you have provided a
sound technical basis for why we should not hold the other ports to the same
standards.
The point here is that Windows is virgin territory for us. We know
about Unix. When we port to a new Unix variant, we are dealing with the
same system APIs, and in many cases large chunks of the same system
code, that we've dealt with before. It's reasonable for us to have
confidence that Postgres will work the same on such a platform as it
does on other Unix variants. And the track record of reliability that
we have built up across a bunch of Unix variants gives us
cross-pollinating confidence in all of them.
Windows shares none of that heritage. It is the first truly new port,
onto a system without any Unix background, that we have ever done AFAIK.
I don't know how much Unix backgroun BeOS has. It does have a better
POSIX support than Win32, but I don't know how much of it is really from
Unix.
Claiming that it doesn't require an increased level of testing is
somewhere between ridiculous and irresponsible.
We should have at least _some_ platforms (besides Win32) that we could
clain to have run thorough test on.
I suspect that RedHat does some (perhaps even severe) testing for
RHAS/RHDB, but I don't know of any other thorough testing.
Or should reliability testing actually be something left for commercial
entities ?
I believe we should test every release as pathologically as Vince
has stated for Win32.
Great, go to it. That does not alter the fact that today, with our
existing port history, Windows has to be treated with extra suspicion.
I don't think that the pull-the-plug scenario happens enough in the wild
that even our seven-year track record can prove anything conlusive about
the reliability. I have not found instructions about providing that kind
of reliability in the docs either - things like what filesystems to use
on what OSes and with which mount options.
We just mention -f as a way to get non-reliable system ;)
I do not buy the argument you are making that we should treat all
platforms alike. If we had a ten-year-old Windows port, we could
consider it as stable as all our other ten-year-old Unix ports.
We don't. Given that we don't have infinite resources for testing,
it's simple rationality to put more testing emphasis on the places
that we suspect there will be problems. And if you don't suspect
there will be problems on Windows, you are being way too naive :-(
We don't have that old windows port, but I guess that there are native
windows ports at least a few years old.
Do we want to encourage Win32? (some obviously do, but I don't) Well, telling
people that we have tested PostgreSQL on Win32 much more thoroughly than on
Unix is in a way telling them that we think it is _better_ than the
time-tested Unix ports ('It passed a harder test on Win32. Are we afraid the
Unix ports won't pass those same tests?').
If it passes the tests, good for it. I honestly do not expect that it
will. My take on this is that we want to be able to document the
problems in advance, rather than be blindsided.
Where can I read such documentations for *nix ports ?
What I have read in this list is that losing different voltages in wrong
order can just write over any sectors on a disk, and that power-cycling
can blow up computers. I don't expect even Unix to survive that!
--
Hannu Krosing [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL, NetBSD and NFS
On Thursday 30 January 2003 18:32, Simon J. Gerraty wrote:
Is postgreSQL trying to lock a file perhaps? Would seem a sensible thing
for it to be doing...
Is that a problem? FWIW I am running statd and lockd on the NetBSD box.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
Jan Wieck [EMAIL PROTECTED] writes: Assuming all your assumptions are right, why the hell is Oracle's and MS SQL-Server's reputation that bloody good? They have marketing departments. ... As well as sizable systems integration departments devoted to the platforms in question. PostgreSQL doesn't have the latter, although the recent efforts make a move towards it. And what about MySQL? What about it? Someone claimed in this thread that MySQL's Windows port requires Cygwin. Is that true or not? http://www.mysql.com/downloads/mysql-3.23.html Windows downloads The Windows binaries use the Cygwin library. Source code for the version of Cygwin we have used is available on this page. http://www.mysql.com/downloads/cygwin.html -- (reverse (concatenate 'string gro.gultn@ enworbbc)) http://www.ntlug.org/~cbbrowne/spiritual.html When you have eliminated the impossible, whatever remains, however improbable, must be the truth. -- Sir Arthur Conan Doyle (1859-1930), English author. Sherlock Holmes, in The Sign of Four, ch. 6 (1889). [...but see the Holmesian Fallacy, due to Bob Frankston... http://www.frankston.com/public/Essays/Holmesian%20Fallacy.asp] ---(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] [OpenFTS-general] relor and relkov
On Fri, 31 Jan 2003, Caffeinate The World wrote: --- Oleg Bartunov [EMAIL PROTECTED] wrote: On Fri, 31 Jan 2003, Caffeinate The World wrote: But, we need help to create good documentation for tsearch ! This is main stopper for releasing of tsearch. I am currently using tsearch. I'd be happy to help with documentation. Nice ! We'll send you archive with new tsearch and short info, so you could test it and write documentation. I have a live DB, is it possible to install the new alpha tsearch module w/o conflicting with the existing production one? I'm afraid, no. it's better to have separate postgres installation. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ OpenFTS-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openfts-general 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 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
On Thu, 2003-01-30 at 15:56, Tom Lane wrote: The reason the TIP is still there is that there are platforms on which that stuff doesn't work very nicely. It's better to let the postmaster exit cleanly so that that state gets cleaned up. I have no idea what the comparable issues are for a native Windows port, but I bet there are some... That's why I proposed an automated test for this too. It is mostly important when conquering new OS'es, but could also be nice to have when testing if changes to storage manager or some other important subsystem will break anything. regards, tom lane -- Hannu Krosing [EMAIL PROTECTED] ---(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 Fri, 31 Jan 2003, D'Arcy J.M. Cain wrote: On Thursday 30 January 2003 12:07, Tom Lane wrote: Perhaps the next thing to do is to strace (ktrace, trace, truss, whatever system-call tracing utility you got) the postmaster and child processes. If we could determine what system call is hanging up, we might be a little closer to solving the mystery. Ktrace. Yes, am doing another test at the moment - using 100Mb to 100Mb and TCP option to the mount. Before I was using the default UDP and going 100Mb to 1000 Mb. If this works I will try my guaranteed fail next and will add ktrace. In fact, I will do that regardless. Look at the -t option to ktrace. It controls what ktrace looks at (syscalls, NAMEI lookups, etc.). Most importantly, you might want to NOT include the 'i' option in there, which is in there by default. It logs the data of all i/o transfers, which baloons the logs. While you may need the data in the end, tracing w/o 'i' could show you the syscalls around the failure which might be enough. Take care, Bill ---(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] PostgreSQL, NetBSD and NFS
D'Arcy J.M. Cain wrote: On Thursday 30 January 2003 14:02, mlw wrote: Forgive my stupidity, are you running PostgreSQL with the data on an NFS share? Yes, sorry. PostgreSQL is running from the local disk but the data is on the mounted drive. I'm not sure, I guess it could work, but NFS is a pretty poor file system. There are always issues with file locking across various platforms. I recall reading about mmap issues across NFS a while ago (forget the platform, sorry). Depending on the NFS server, there may be problems there. The NFS client may also have isses with locking, fsync, and mmap. If possible, look for a network block device protocol. The file level NFS is probably inadequate for PostgreSQL. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL, NetBSD and NFS
On Thursday 30 January 2003 12:07, Tom Lane wrote:
D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
I have posted before about this but I am now posting to both NetBSD and
PostgreSQL since it seems to be some sort of interaction between the two.
I have a NetAPP filer on which I am putting a PostgreSQL database. I
run PostgreSQL on a NetBSD box. I used rsync to get the database onto
the filer with no problem whatsoever but as soon as I try to open the
database the NFS mount hangs and I can't do any operations on that
mounted drive without hanging.
That's darn odd. But please be more specific: what's open the
database? Start the postmaster? Start a psql? Issue a query?
Start the postmaster. It is possible that I have a corrupted database but I
was using that as a debugging tool because I still don't think that the whole
NFS subsystem should lock up. The other time I tested it took hours to fail
and I found it useful to have an immediate fail.
Perhaps the next thing to do is to strace (ktrace, trace, truss,
whatever system-call tracing utility you got) the postmaster and
child processes. If we could determine what system call is hanging up,
we might be a little closer to solving the mystery.
Ktrace. Yes, am doing another test at the moment - using 100Mb to 100Mb and
TCP option to the mount. Before I was using the default UDP and going 100Mb
to 1000 Mb. If this works I will try my guaranteed fail next and will add
ktrace. In fact, I will do that regardless.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 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 Thursday 30 January 2003 14:27, Greg Copeland wrote:
That was going to be my question too.
I thought NFS didn't have some of the requisite file system behaviors
(locking, flushing, etc. IIRC) for PostgreSQL to function correctly or
reliably.
Please correct as needed.
Yes, doubly so here please. I think I remember someone else saying that they
use PostgreSQL over NFS so hopefully this is not the situation.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL, NetBSD and NFS
On Thursday 30 January 2003 14:02, mlw wrote:
Forgive my stupidity, are you running PostgreSQL with the data on an NFS
share?
Yes, sorry. PostgreSQL is running from the local disk but the data is on the
mounted drive.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 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] [OpenFTS-general] relor and relkov
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]
Re: [mail] Re: [HACKERS] Windows Build System
-Original Message- From: Dave Page Sent: 30 January 2003 19:57 To: Vince Vielhaber; Lamar Owen Cc: [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Windows Build System I ought to plonk you for a comment like that. Especially coming from the person who's crap I've been trying to sort out for the last couple of months. Apologies for that folks. Momentary lack of good judgement on my part. Regards, Dave. ---(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] [OpenFTS-general] relor and relkov
On Fri, 31 Jan 2003, Caffeinate The World wrote: But, we need help to create good documentation for tsearch ! This is main stopper for releasing of tsearch. I am currently using tsearch. I'd be happy to help with documentation. Nice ! We'll send you archive with new tsearch and short info, so you could test it and write documentation. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com 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 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
On Friday 31 January 2003 05:08, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: And what about MySQL? What about it? Someone claimed in this thread that MySQL's Windows port requires Cygwin. Is that true or not? For reference, from the INSTALL-SOURCE file included in the MySQL sources which I have lying about [*]: [*] danged legacy applications ;-) --QUOTE START-- Windows Source Distribution --- You will need the following: * VC++ 6.0 compiler (updated with 4 or 5 SP and Pre-processor package) The Pre-processor package is necessary for the macro assembler. More details at: `http://msdn.microsoft.com/vstudio/sp/vs6sp5/faq.asp'. * The MySQL source distribution for Windows, which can be downloaded from `http://www.mysql.com/downloads/'. Building MySQL 1. Create a work directory (e.g., workdir). 2. Unpack the source distribution in the aforementioned directory. 3. Start the VC++ 6.0 compiler. 4. In the `File' menu, select `Open Workspace'. 5. Open the `mysql.dsw' workspace you find on the work directory. 6. From the `Build' menu, select the `Set Active Configuration' menu. 7. Click over the screen selecting `mysqld - Win32 Debug' and click OK. 8. Press `F7' to begin the build of the debug server, libs, and some client applications. 9. When the compilation finishes, copy the libs and the executables to a separate directory. 10. Compile the release versions that you want, in the same way. 11. Create the directory for the MySQL stuff: e.g., `c:\mysql' 12. From the workdir directory copy for the c:\mysql directory the following directories: * Data * Docs * Share 13. Create the directory `c:\mysql\bin' and copy all the servers and clients that you compiled previously. 14. If you want, also create the `lib' directory and copy the libs that you compiled previously. 15. Do a clean using Visual Studio. Set up and start the server in the same way as for the binary Windows distribution. *Note Windows prepare environment::. --QUOTE END-- Ian Barwick [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Odd website behavior...
-Original Message- From: Greg Copeland [mailto:[EMAIL PROTECTED]] Sent: 31 January 2003 16:12 To: PostgresSQL Hackers Mailing List Subject: [HACKERS] Odd website behavior... When searching techdocs.postgresql.org, if you type in transaction, it says, Your original search: transation returned zero results. The alternate spelling: transaction returned the results below. For some reason it is changing the spelling and then reverting back to the original. Just a heads up that something funky is going on. ;) Works for me: http://www.postgresql.org/search.cgi?q=transactionm=allwm=wrdul=http% 3A%2F%2Ftechdocs.postgresql.org%2Fwf=10 Or do you mean the old Google one? Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Win32 port powerfail testing
Despite some people's thoughts that a powerfail test is of little use, I going to spend some time doing one anyway because I think Tom's arguments for it are valid. I have lashed together the attached test program (the important bits are the setup, run and check functions) for review before I actually do anything next week. Comments, suggestions etc are welcome, though I don't have the time to write anything too complex, but do want to perform a valid test first time round if possible. 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?). The number of runs will be dictated by my workload next week, but I'd like to do at least 20 powerfails on each OS. Regards, Dave. pgtest.c Description: pgtest.c ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
Tom Lane wrote: Curtis Faith [EMAIL PROTECTED] writes: If a developer can simply download the source, click on the Visual C++ project in the win32 directory and then build PostgreSQL, and they can see that Windows is not the poor stepchild because the VC project is well laid out, they will be more likely to use it for Windows projects than MySQL which requires the CygWin tools (this means really a Unix product to Windows developers). flame on In all honesty, I do not *want* Windows people to think that they're not running on the poor stepchild platform.If we go down that path, they'll start trying to run production databases on Windows, and then we'll get blamed for the instability of the platform, not to mention the likelihood that it ignores Unix semantics for fsync() and suchlike critical primitives. I have no objection to there being a Windows port that people can use to do SQL-client development on their laptops. But let us please not confuse this with an industrial-strength solution; nor give any level of support that might lead others to make such confusion. The MySQL guys made the right choice here: they don't want to buy into making Windows a grade-A platform, either. flame off OK, I have to weigh in here. I have been a Windows application and kernel driver developer since version 1.0. I have also worked on UNIX since the original Sun machines. Yes, the DOS version of Windows, i.e win95/98/ME is pure unmitigated crap. No doubt. The NT version of Windows, NT/2K/XP has a very well designed kernel. It is more or less based on OpenVMS. To say it is a poor stepchild shows a lack of imagination on your part. The NT lineage of Windows is usable as a production server. I think PostgreSQL using the most pedestrian Win32 API entry points will perform just fine. The core disk I/O subsystem and NTFS are very stable. The scheduler is not great, but is usable. The VM system is probably better than most UNIX environments, including FreeBSD and Linux. The always interruptable always reentrant device driver design could crank out some serious performance on a busy server. That being said, the kernel level GUI of Windows is a dangerous risk. Many of the changes made since the original NT (3.x) do reduce stability in a desktop environment. However, a server environment, such as PG, which does not perform any graphic interactions should be stable enough. If rebooted once a every month or two, the system should never experience data loss and windows admins are used to doing periodic reboots. One last, IMHO very important point, A LOT OF PEOPLE USE WINDOWS! Every effort should be made to support it. Yea, we all have our favorite environments. I choose Linux, others choose a *BSD, some use HPUX, Solaris or whatever. The point is a lot people choose Windows. It is possible to make a stable environment on this platform. Would I choose it? No, but some people do. Don't you think it makes sense to provide a good solution on Windows, and if they run into the inherent limitations of that platform be able to say, Windows has some serious design flaws, but you can upgrade to Solaris or HPUX if you need and getting the user, instead of saying, Windows sucks, use a real platform and losing them? I think it is a AWESOME story to say, Build your app using PG. Start with Windows, if you like, we don't care, if you grow beyond the capabilities of Windows, just upgrade your server, no need to change anything else. Just my $0.02 Mark ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Odd website behavior...
-Original Message- From: Greg Copeland [mailto:[EMAIL PROTECTED]] Sent: 31 January 2003 19:45 To: Dave Page Cc: PostgresSQL Hackers Mailing List Subject: RE: [HACKERS] Odd website behavior... Or do you mean the old Google one? Regards, Dave. I'm going to guess and say, yes. Since the old google one is the only search mechanism that I've seen. I'm surprised to read that there is another mechanism. Yes, it;s only a few days old - part of the ongoing website overhaul. Perhaps the old google one can be done away with as your results page has a nice look and certainly was much more effective. Justin? We can write a techdocs styled search/results page quite easily if you like that will use the same database, and filter to techdocs only if that's preferred. It would be nice to get rid of Google. Regards, Dave. ---(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] sync()
On Mon, Jan 13, 2003 at 07:31:08PM +1100, Giles Lean wrote: Is the Single Unix Standard, version 2 (aka UNIX98) any better? It says for fsync(): The fsync() function forces all currently queued I/O operations associated with the file indicated by file descriptor fildes to the synchronised I/O completion state. All I/O operations are completed as defined for synchronised I/O file integrity completion. In version 3 it says: The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes in an implementation-defined manner. The fsync() function shall not return until the system has completed that action or until an error is detected. [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] Kurt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 port powerfail testing
Dave Page kirjutas R, 31.01.2003 kell 22:36: Despite some people's thoughts that a powerfail test is of little use, I going to spend some time doing one anyway because I think Tom's arguments for it are valid. I have lashed together the attached test program (the important bits are the setup, run and check functions) for review before I actually do anything next week. Comments, suggestions etc are welcome, though I don't have the time to write anything too complex, but do want to perform a valid test first time round if possible. 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?). I think that ext3 should be more reliable, or at least more mainstream - I have had bad experience with raiserfs not too long ago - a crash (similar to pull-the-plug) zeroed out completely unrelated files (files not recently written to, just read). As I don't use Slackware anymore (though I started usin linux on it in the dark ages before 1.0 kernel), I don't know if the issues are fixed there. The number of runs will be dictated by my workload next week, but I'd like to do at least 20 powerfails on each OS. Don't post if you happen to get better results for win32 ;) I have a worried lung-doctor (aka pulmonologist) friend who did some research/statistics on influence of smoking and he is desperate as his methodologically completely scientific studies ended up showing that smoking is healthy and not smoking is not ;), so he seems unable to publish any of his results in any respectable outlet ;( -- Hannu Krosing [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: [HACKERS] Windows Build System - My final thoughts
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? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
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. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Odd website behavior...
Dave Page wrote: snip Justin? We can write a techdocs styled search/results page quite easily if you like that will use the same database, and filter to techdocs only if that's preferred. It would be nice to get rid of Google. Agreed. It would be better to have Dave improved search engine do it. Are you guys fine with ripping out the Google one and putting the new one in? There is no chance I'm going to have time to do much in the way of assisting at the moment. :( Regards and best wishes, Justin Clift Regards, Dave. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PERFORM] not using index for select min(...)
I have a table which is very large (~65K rows). I have a column in it which is indexed, and I wish to use for a join. I'm finding that I'm using a sequential scan for this when selecting a MIN. Due to Postgres' system of extensible aggregates (i.e. you can write your own aggregates), all aggregates will trigger a Seq Scan in a query. It's a known drawrback that nobody has yet found a good way around. I've spent some time in the past thinking about this, and here's the best idea that I can come up with: Part one: setup an ALTER TABLE directive that allows for the addition/removal of cached aggregates. Ex: ALTER TABLE tab1 ADD AGGREGATE CACHE ON count(*); ALTER TABLE tab1 ADD AGGREGATE CACHE ON sum(col2); ALTER TABLE tab1 ADD AGGREGATE CACHE ON sum(col2) WHERE col2 100; ALTER TABLE tab1 ADD AGGREGATE CACHE ON sum(col2) WHERE col2 = 100; Which would translate into some kind of action on a pg_aggregate_cache catalog: aggregate_cache_oid OID -- OID for the aggregate cache aggregate_table_oid OID -- table OID ins_aggfn_oid OID -- aggregate function id for inserts upd_aggfn_oid OID -- aggregate function id for updates del_aggfn_oid OID -- aggregate function id for deletes cache_value INT -- the value of the cache private_data INT[4] -- temporary data space for needed -- data necessary to calculate cache_value -- four is just a guesstimate for how much -- space would be necessary to calculate -- the most complex of aggregates where_clause ??? -- I haven't the faintest idea how to -- express some kind of conditional like this Part two: setup a RULE or TRIGGER that runs on INSERT, UPDATE, or DELETE. For the count(*) exercise, the ON UPDATE would be a no-op. For ON INSERT, the count(*) rule would have to do something like: UPDATE pg_catalog.pg_aggregate_cache SET cached_value = (cached_value + 1) WHERE aggregate_cache_oid = 111; For the sum(col2) aggregate cache, the math is a little more complex, but I think it's quite reasonable given that it obviates a full table scan. For an insert: UPDATE pg_catalog.pg_aggregate_cache SET cached_value = ((cached_value * private_data[0] + NEW.col2) / (private_data[0] + 1)) WHERE aggregate_cache_oid = 112; Now, there are some obvious problems: 1) avg requires a floating point return value, therefore an INT may not be an appropriate data type for cache_value or private_data. 2) aggregate caching wouldn't speed up anything but full table aggregates or regions of a column that are frequently needed. 3) all of the existing aggregates would have to be updated to include an insert, update, delete procedure (total of 60 aggregates, but only 7 by name). 4) the planner would have to be taught how to use/return values from the cache. 5) Each aggregate type makes use of the private_data column differently. It's up to the cached aggregate function authors to not jumble up their private data space. 6) I don't know of a way to handle mixing of floating point numbers and integers. That said, there's some margin of error that could creep into the floating point calculations such as avg. And some benefits: 1) You only get caching for aggregates that you frequently use (sum(col2), count(*), etc.). 2) Aggregate function authors can write their own caching routines. 3) For tens of millions of rows, it can be very time consuming to sum() fifty million rows, but it's easy to amortize the cost of updating the cache on insert, update, delete over the course of a month. 4) If an aggregate cache definition isn't setup, it should be easy for the planner to fall back to a full table scan, as it currently is. This definitely would be a performance boost and something that would only be taken advantage of by DBAs that are intentionally performance tuning their database, but for those that do, it could be a massive win. Thoughts? -sc -- Sean Chittenden ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PERFORM] not using index for select min(...)
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. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Windows Build System - My final thoughts
Bruce Momjian wrote: snip So, as far as I am concerned, we will have a Win32 port in 7.4. It will not be perfect, but it will be as good as we can do. We are also getting point-in-time recovery in 7.4, so that may help us with Win32 port failures too. If anyone's interested, the PostgreSQL 7.3.1 Proof of Concept for Windows Alpha 1 (yes the warnings are even built into the name) easy-installer that I whipped up using Inno Setup was quietly uploaded to the pgsql project on Sourceforge the other night. It's using PostgreSQL + cygwin, pretty much stock standard but pre-installed and wrapped up into a single installable. As an indicater, having made no release annoucement, and only having put a one paragraph small mention with a link to it on the Techdocs Installing On Windows page (with warnings), over 1,600 people downloaded it in the first 24 hours (that's about 17.1 GB of bandwidth). This was just a version so that I could practise some windows packaging and see what kind of things we'd need to address. Dave has already pointed out that we're probably going to need to do this so it can be made into a Merge Module and other things. A couple of bits of interest turned up whilst packaging: + There are unix command line tools that PostgreSQL relies on. For example, when running initdb, it errors out if some tools aren't present. i.e. sed, grep, ash (cygwin's /bin/sh), and from memory a few others + GPL licensing issues. Am trying to get my head around the implications - with regards to licensing - if we released a proper version with some of the cygwin tools included... i.e. grep, sed, etc. Don't think that places could use it embedded with their products and not at least have source available, but still haven't totally grokked this all completely yet. Not going to commit any code to the GBorg project that was setup the other day until this is sorted out. PostgreSQL 7.4 on Win32 should be properly BSD too. + Aside from all this, it might be nice to have a few Win32 specific gui pieces in place at the time that PostgreSQL 7.4 Win32 is released. Am sure they'll develop over time, but was thinking we should at least make a good impression with the first release. Hey, if we make a really bad impression with the first release, then there might not be the quadruple-zillion Windows PG users after all. If that sounds like a good idea, maybe adding the GUC variables random_query_delay (minutes), crash_how_often (seconds), and reboot_plus_corrupt_please (true/false)? Regards and best wishes, Justin Clift -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PERFORM] not using index for select min(...)
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. I never claimed it was perfect, :) but it'd be is no worse than a table lock. For the types of applications that this would be of biggest use to, there would likely be more reads than writes and it wouldn't be as bad as one could imagine. A few examples: # No contension Transaction A begins Transaction A updates tab1 Transaction B begins Transaction B updates tab1 Transaction B commits Transaction A commits # contension Transaction A begins Transaction A updates tab1 Transaction B begins Transaction B updates tab1 Transaction A commits Transaction B commits This is just about the only case that I can see where there would be contension. In this case, transaction B would have to re-run its trigger serially. In the worse case scenario: Transaction A begins Transaction A updates tab1 Transaction B begins Transaction B updates tab1 Transaction A commits Transaction B selects Transaction B updates tab1 again Transaction B commits In my journals or books I haven't found any examples of a transaction based cache that'd work any better than this. It ain't perfect, but, AFAICT, it's as good as it's going to get. The only thing that I could think of that would add some efficiency in this case would be to have transaction B read trough the committed changes from a log file. After a threshold, it could be more efficient than having transaction B re-run its queries. Like I said, it ain't perfect, but what would be a better solution? ::shrug:: Even OODB's with stats agents have this problem (though their overhead for doing this kind of work is much much lower). -sc -- Sean Chittenden ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] COPY as non super user
how should I use COPY arti FROM 'ARTI.txt' USING DELIMITERS '|' as normal user ? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [ADMIN] COPY as non super user
On Fri, Jan 31, 2003 at 11:13:04 +0100, Jaume Teixi [EMAIL PROTECTED] wrote: how should I use COPY arti FROM 'ARTI.txt' USING DELIMITERS '|' as normal user ? If you are using psql, use the \copy command. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
