Re: [mail] Re: [HACKERS] Windows Build System
On Wed, 29 Jan 2003, Ron Mayer wrote: Cool irony in the automated .sig on the mailinglist software... On Wed, 29 Jan 2003, Vince Vielhaber wrote: ... hammering the betas is a far cry from an industrial-strength solution. ... TIP 4: Don't 'kill -9' the postmaster Sounds like you're basically saying is _do_ 'kill -9' the postmaster... and make sure it recovers gracefully when testing for an industrial- strength solution. Not what I said at all. 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Linux.conf.au 2003 Report
On Thu, 30 Jan 2003, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Maybe we should create a new type 'inet6'??? I'd lean towards allowing the existing inet and cidr types to store both v4 and v6 addresses, if at all possible. Is there a good motivation for doing otherwise? Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra 96 bits of storage?). Use of ipv4 and ipv6 should be mutually exclusive. Extra code in inet type causing bloat. regards, tom lane Gavin ---(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] v7.2.4 bundled ...
bash-2.05b$ bison --version bison (GNU Bison) 1.75 ISTM that the eve of what'll probably be our last dot-release for 7.2 is not the time to drop a new bison into its toolchain. Agreed -- but it's worth mentioning in the 7.2.4 release notes that an earlier Bison version is required. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] v7.2.4 bundled ...
Kevin Brown [EMAIL PROTECTED] writes: I'm attaching a patch for 7.2.4's parser/gram.y that fixes all of bison 1.75's complaints. But parser/gram.y is not the only .y file in the distribution. To call ourselves 1.75-safe, we'd have to go through this same exercise for all of 'em: $ find REL7_2 -name '*.y' REL7_2/pgsql/contrib/cube/cubeparse.y REL7_2/pgsql/contrib/seg/segparse.y REL7_2/pgsql/src/backend/bootstrap/bootparse.y REL7_2/pgsql/src/backend/parser/gram.y REL7_2/pgsql/src/interfaces/ecpg/preproc/preproc.y REL7_2/pgsql/src/pl/plpgsql/src/gram.y $ And on top of that, 1.75 isn't the current bison release anymore; the one that is current has changed the spelling of syntax error messages, which means that the regression tests will fail (and perhaps clients that are looking for syntax errors, too). We have agreed how to fix this in HEAD, but not actually done it yet --- shall we put that not-even-written-let-alone-tested code into 7.2.4 as well? I think it's best to leave well enough alone. The tarball ships with working bison output files anyway, so all of this really only matters to people trying to build 7.2.* from a CVS pull. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Linux.conf.au 2003 Report
What about cases where I only want one or the other? Would a simple method exist to limit input to v4 or v6 only? Also, what are the implications to functions such as network_sub, network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the two are freely mixed in the same data type? Cheers, Steve On Wednesday 29 January 2003 10:04 pm, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Maybe we should create a new type 'inet6'??? I'd lean towards allowing the existing inet and cidr types to store both v4 and v6 addresses, if at all possible. Is there a good motivation for doing otherwise? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Linux.conf.au 2003 Report
Steve Crawford [EMAIL PROTECTED] writes: What about cases where I only want one or the other? Would a simple method exist to limit input to v4 or v6 only? I would assume we'd add a test function like is_v6(inet). Given that, you could add a check constraint is_v6(col) or NOT is_v6(col) to any column that you want to restrict. Also, what are the implications to functions such as network_sub, network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the two are freely mixed in the same data type? 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. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL, NetBSD and NFS
D'Arcy J.M. Cain [EMAIL PROTECTED] writes: 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? Does the shared memory stuff use disk at all? No, I can't see that there would be any connection there. 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. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] A call for PostreSQL Case Study participants
Hi everyone, This is a call for PostgreSQL Case Study participants. We're looking for volunteers running PostgreSQL in their companies, or who have good contact with companies running PostgreSQL, to please assist us in creating a large number of good quality, reference PostgreSQL Case Studies. Carol Ioanni [EMAIL PROTECTED] will be assisting the PostgreSQL Global Development Group for the next few weeks by working with businesses who volunteer to be a part of this PostgreSQL initiative. We really need everyone to get the go-ahead from the appropriate people in their companies or clients, and then email Carol so she can begin the PostgreSQL Case Study creation process with them. It's fairly simple, just a matter of filling out a detailed worksheet with information about why PostgreSQL was chosen, and a few simple details about the implementation, plus signing a waiver to legally let us use the information. These PostgreSQL Case Studies will be profiled on the PostgreSQL Advocacy and Marketing website, with links where appropriate to the participating organisations, or their referenced product pages: http://advocacy.postgresql.org/casestudies We feel we need enough PostgreSQL Case Studies to categorise them by industry segment (i.e. finance, agricultural, telecommunications) and also by the size of the enterprises themselves (i.e. small business, medium enterprise, etc). Hoping you can help us out. 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] v7.2.4 bundled ...
7.2.x isn't bison 1.75 compatible ... and most likely never will be ... On Wed, 29 Jan 2003, Rod Taylor wrote: I jsut bundled up v7.2.4 with all the recent security fixes ... can a few ppl do some regression tests and report back before I announce in the morning? I did a configure and build here and all looks fine, but some confirmations is always nice ;) Updated to tag REL7_2_4 on FreeBSD 4.7 and cannot compile it. gram.y errors complaining: invalid character: ','. bash-2.05b$ bison --version bison (GNU Bison) 1.75 Written by Robert Corbett and Richard Stallman. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 09:48:37AM -0500, Tom Lane wrote: I don't see the argument for that. (It'd have to be an argument that doesn't just establish a scenario where you'd want that, but proves that we should force that point of view upon every application using IP addresses.) Given that IPv6 is supposed to allow co-operation with IPv4, it seems it'd be pretty hard to force such a view on every application using IP addresses. DNS, for instance. 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: [mail] Re: [HACKERS] Windows Build System
-Original Message- From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] Sent: 30 January 2003 19:20 To: Lamar Owen Cc: Tom Lane; Dave Page; Ron Mayer; [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Windows Build System I've been on both sides know that the windows user/developer doesn't hold things to the same standards as the unix user/developer. 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. Since you're pretty much ignoring my reasoning, I'll give you the same consideration. The history of windows as a platform has shown itself to be rather fragile compared to unix. When properly configured, Windows can be reliable, maybe not as much as Solaris or HPUX but certainly some releases of Linux (which I use as well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable enough. Before you respond to this, read Tom Lane's response and reply to that. *I* did. I volunteered to do some more of the testing we're all so resistant. Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
On Thursday 30 January 2003 16:54, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: And, by the way, who in their right mind tests a database server by repeated yanking of the AC power? Anybody who would like their data to survive a power outage. I don't buy that. That's why I have $36,000 worth of lead acid in the room next door, with $5,000 of inverters and chargers in the server room. Until I had to upgrade RAM I had 240+ days of uptime on one box. The longest power interruption was 28 hours. The battery held the whole time. There was never more than 30 days between interruptions. The last time I had the server actually power down was during a maintenance run on the inverter/charge system, and I had to transfer power to the servers onto another branch, necessitating two power cycles, which were clean shutdown/reboots. I haven't had an unscheduled dirty powerdown in two years. We cannot on any system guarantee the data surviving a sudden power outage. Until we can be certain the write-back cache on that high performance drive (or NAS array using iSCSI, perhaps) flushes we cannot know the data hit the disks. To go to that extreme for Win32 when we caution against something as mundane as a kill -9 of postmaster on Unix is absurd. And, yes, I know the difference. I also know that the AC power pull has nothing to do with PostgreSQL, but it has to do with the OS under it. Although a kill -9, from the point of view of the running process, is identical to a power failure. No, it is not. Did you not read my comments earlier today? Of course I did -- I'm not daft. And that's why I specified 'from the point of view of the running process' -- that is, the process you are SIGKILLing cannot itself determine the difference between the power cycle and SIGKILL. It just simply goes down, hard. Of course there is: I forgot to mention one of the biggest headaches, which is that kill -9 the postmaster doesn't kill the child backends. This is a real difference, and one that I forgot as well. So SIGKILL is different to the whole backend system, but not to the singular process that is being SIGKILL'd. Suppose I issue a SIGKILL to postmaster and all forked backends simultaneously? Where does SIGKILL differ from a power failure from the point of view of the database system in that scenario? This is also assuming that you clean reboot the OS after the SIGKILL to postmaster, as there is that dynamic state you mentioned to worry about. I probably should have mentioned that before. Windows is going to bring a whole new set of failure modes that we don't have defenses for. (Yet.) *That* is what we need extensive testing to learn about, and claiming that we are discriminating against Windows just because it's Windows misses the point completely. And ISTM that an experienced Windows developer, such as Katie or Dave, would know to do this, would know how to do this, and would know the best way of doing this. And I wasn't singling you out, Tom. It was the whole thread and the turns it took that got me rather upset. Or, if you prefer, we can ship Postgres 7.4 for Windows with no more testing than we need for any of the existing, long-since-well-tested ports. But I'll bet a great deal that our reputation will go down the drain (along with many people's data) if we do that. We don't have a standard testing methodology for any of our ports. We need one for all of our ports. I fully expect the Win32 port to need a different methodology than the FreeBSD port or the Linux port. And I expect we have enough experienced Win32 developers (which I am not) here that can provide insight into how the methodologies should differ. I prefer more extensive testing for all of our ports. You did read that when I wrote it, right? (When I wrote it multiple times) Just saying 'it passed regression' shouldn't be enough -- but we should really spend some cycles thinking about what the test suite really should be. For all platforms. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] plpython fails its regression test
In CVS tip, if you run make installcheck in src/pl/plpython, the test fails with a number of diffs between the expected and actual output. I'm not sure if plpython is broken, or if it's just that someone changed the behavior and didn't bother to update the test's expected files (the test files don't seem to have been maintained since they were first installed). Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: I would also point out that we already list the Cygwin port of PostgreSQL as supported. Who ever gave that the kind of testing people are demanding now? I think the worst case scenario will be that our Win32 port is far better than the existing 'supported' solution. A good point --- but what this is really about is expectations. If we support a native Windows port then people will probably think that it's okay to run production databases on that setup; Sure. But it's only common sense that a piece of software is only as reliable as the platform it's running on. People run production databases under MS-SQL all the time. Has MS-SQL itself gained a reputation for being an unreliable piece of junk? Perhaps. But if so, that obviously hasn't stopped people from putting their production databases on it! Is MS-SQL's reputation for unreliability, if any, because of MS-SQL itself or the platform it's operating on? The way to answer that is to ask the same question of Oracle and DB/2 under Windows. And therefore, the answer seems to be that the platform is a minor determinant, if any. whereas I doubt many people would think that about the Cygwin-based port. Why not? Seriously, if the people in question are the simpletons that you appear to be expecting them to be, then wouldn't they have that same expectation of the Cygwin based port? Why not? So what we need to know is whether the platform is actually stable enough that that's a reasonable thing to do; so that we can plaster the docs with appropriate disclaimers if necessary. Well, shouldn't we do that anyway, then, until we know otherwise? Shouldn't we do that with *any* new port? Windows, unlike the other OSes mentioned in this thread, has a long enough and sorry enough track record that it seems appropriate to run such tests ... With this I agree, but before you start thinking that Windows is the only OS that qualifies, consider this: I've run the pull the plug test under early Linux 2.4 kernels running with ReiserFS. I'd start a make of a large project, pull the power, bring the system back up, and restart the build. And the end result was that some of the files files in the build directory were corrupted, such that the build could not continue. I haven't tried this under current versions of the kernel, so I don't know if things have improved or not. Doesn't that -- shouldn't that -- give you pause about declaring *Linux* an industrial-strength solution? My point: if you're going to hold *one* OS to a given standard, you should hold *all* of them to that same standard. -- Kevin Brown [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: [PATCHES] [HACKERS] v7.2.4 bundled ...
Tom Lane wrote: Kevin Brown [EMAIL PROTECTED] writes: I'm attaching a patch for 7.2.4's parser/gram.y that fixes all of bison 1.75's complaints. But parser/gram.y is not the only .y file in the distribution. To call ourselves 1.75-safe, we'd have to go through this same exercise for all of 'em: $ find REL7_2 -name '*.y' REL7_2/pgsql/contrib/cube/cubeparse.y REL7_2/pgsql/contrib/seg/segparse.y REL7_2/pgsql/src/backend/bootstrap/bootparse.y REL7_2/pgsql/src/backend/parser/gram.y REL7_2/pgsql/src/interfaces/ecpg/preproc/preproc.y REL7_2/pgsql/src/pl/plpgsql/src/gram.y $ I'll be happy to go through the same process for those files. And on top of that, 1.75 isn't the current bison release anymore; the one that is current has changed the spelling of syntax error messages, which means that the regression tests will fail (and perhaps clients that are looking for syntax errors, too). We have agreed how to fix this in HEAD, but not actually done it yet --- shall we put that not-even-written-let-alone-tested code into 7.2.4 as well? I assume you're referring to the use of error numbers here. Yes, I agree that *that* code shouldn't go into 7.2.4. I think it's best to leave well enough alone. The tarball ships with working bison output files anyway, so all of this really only matters to people trying to build 7.2.* from a CVS pull. Okay, fair enough, but if we intend to continue to maintain 7.2.*, shouldn't we at least fix the .y files? We can hack configure to fail if it detects a bison later than 1.75, or we can simply put something in the release notes that says if the regressions fail on error detection it may mean that an incompatible bison was used. -- Kevin Brown [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] plpython fails its regression test
On Thu, 2003-01-30 at 16:39, Tom Lane wrote: In CVS tip, if you run make installcheck in src/pl/plpython, the test fails with a number of diffs between the expected and actual output. I'm not sure if plpython is broken, or if it's just that someone changed the behavior and didn't bother to update the test's expected files (the test files don't seem to have been maintained since they were first installed). Comments? Could this have anything to do with the changes I made to the python stuff to get it to support longs (IIRC)? It's been a while now so I don't recall exactly what got changed. I do remember that I chanced some test code to ensure it tested the newly fixed data type. Regards, -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
Greg Copeland wrote: On Thu, 2003-01-30 at 13:56, Dave Page wrote: When properly configured, Windows can be reliable, maybe not as much as Solaris or HPUX but certainly some releases of Linux (which I use as well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable enough. I'm not jumping on one side or the other but I wanted to make clear on something. The fact that IBM or Oracle use windows has absolutely zero to do with reliability or stability. They are there because the market is willing to spend money on their product. Let's face it, the share holders of each respective company would come unglued if the largest software audience in the world were completely ignored. Simple fact is, your example really is pretty far off from supporting any view. Bluntly stated, both are in that market because they want to make money; they're even obligated to do so. That's true, but it ignores the question that makes it relevant: has their appearance in the Windows market tarnished their reputation? More precisely, has it tarnished their reputation in the *Unix* community? The answer, I think, is no. And that *is* relevant to us, because our concern is about the reputation of PostgreSQL, and what will happen to it if we release a native Windows port to the world. Of course, you could argue that Oracle and IBM didn't have much of a reputation anyway, and I wouldn't be able to say much to that. :-) -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
On Thu, Jan 30, 2003 at 02:39:59PM -0800, Kevin Brown wrote: With this I agree, but before you start thinking that Windows is the only OS that qualifies, consider this: I've run the pull the plug test under early Linux 2.4 kernels running with ReiserFS. I'd start a make of a large project, pull the power, bring the system back up, and restart the build. And the end result was that some of the files files in the build directory were corrupted, such that the build could not continue. Afaik, ReiserFS does not guarantee data consistency, only meta data. As in, the file system itself will be consistent, and an fsck shouldn't find a problem. Kurt ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] plpython fails its regression test
Greg Copeland [EMAIL PROTECTED] writes:
On Thu, 2003-01-30 at 16:39, Tom Lane wrote:
In CVS tip, if you run make installcheck in src/pl/plpython, the test
fails with a number of diffs between the expected and actual output.
Could this have anything to do with the changes I made to the python
stuff to get it to support longs (IIRC)?
The diffs seem to have more to do with error handling --- see attached.
None of the plpython files have changed since November, btw, so I would
imagine you'll see the same behavior in 7.3 or 7.3.1; but I haven't
rebuilt that branch to confirm it.
regards, tom lane
--- error.expected 2002-03-06 13:50:31.0 -0500
+++ error.output2003-01-30 17:18:23.0 -0500
@@ -1,12 +1,15 @@
SELECT invalid_type_uncaught('rick');
-WARNING: plpython: in function __plpython_procedure_invalid_type_uncaught_49801:
-plpy.SPIError: Cache lookup for type `test' failed.
+WARNING: plpython: in function __plpython_procedure_invalid_type_uncaught_154373:
+plpy.SPIError: Unknown error in PLy_spi_prepare.
+ERROR: Type test does not exist
SELECT invalid_type_caught('rick');
-WARNING: plpython: in function __plpython_procedure_invalid_type_caught_49802:
-plpy.SPIError: Cache lookup for type `test' failed.
+WARNING: plpython: in function __plpython_procedure_invalid_type_caught_154374:
+plpy.SPIError: Unknown error in PLy_spi_prepare.
+ERROR: Type test does not exist
SELECT invalid_type_reraised('rick');
-WARNING: plpython: in function __plpython_procedure_invalid_type_reraised_49803:
-plpy.SPIError: Cache lookup for type `test' failed.
+WARNING: plpython: in function __plpython_procedure_invalid_type_reraised_154375:
+plpy.SPIError: Unknown error in PLy_spi_prepare.
+ERROR: Type test does not exist
SELECT valid_type('rick');
valid_type
@@ -14,20 +17,20 @@
(1 row)
SELECT read_file('/etc/passwd');
-ERROR: plpython: Call of function `__plpython_procedure_read_file_49809' failed.
+ERROR: plpython: Call of function `__plpython_procedure_read_file_154381' failed.
exceptions.IOError: can't open files in restricted mode
SELECT write_file('/tmp/plpython','This is very bad');
-ERROR: plpython: Call of function `__plpython_procedure_write_file_49810' failed.
+ERROR: plpython: Call of function `__plpython_procedure_write_file_154382' failed.
exceptions.IOError: can't open files in restricted mode
SELECT getpid();
-ERROR: plpython: Call of function `__plpython_procedure_getpid_49811' failed.
-exceptions.AttributeError: getpid
+ERROR: plpython: Call of function `__plpython_procedure_getpid_154383' failed.
+exceptions.AttributeError: 'module' object has no attribute 'getpid'
SELECT uname();
-ERROR: plpython: Call of function `__plpython_procedure_uname_49812' failed.
-exceptions.AttributeError: uname
+ERROR: plpython: Call of function `__plpython_procedure_uname_154384' failed.
+exceptions.AttributeError: 'module' object has no attribute 'uname'
SELECT sys_exit();
-ERROR: plpython: Call of function `__plpython_procedure_sys_exit_49813' failed.
-exceptions.AttributeError: exit
+ERROR: plpython: Call of function `__plpython_procedure_sys_exit_154385' failed.
+exceptions.AttributeError: 'module' object has no attribute 'exit'
SELECT sys_argv();
sys_argv
--- feature.expected2002-10-15 11:24:17.0 -0400
+++ feature.output 2003-01-30 17:18:23.0 -0500
@@ -36,9 +36,10 @@
(1 row)
SELECT import_succeed();
- import_succeed
-
- succeeded, as expected
+NOTICE: ('import failed -- No module named _sre',)
+ import_succeed
+
+ failed, that wasn't supposed to happen
(1 row)
SELECT import_test_one('sha hash of this string');
@@ -56,9 +57,9 @@
select argument_test_one(users, fname, lname) from users where lname = 'doe' order by
1;
argument_test_one
-
- jane doe = {'fname': 'jane', 'userid': 1, 'lname': 'doe', 'username': 'j_doe'}
- john doe = {'fname': 'john', 'userid': 2, 'lname': 'doe', 'username': 'johnd'}
- willem doe = {'fname': 'willem', 'userid': 3, 'lname': 'doe', 'username': 'w_doe'}
+ jane doe = {'lname': 'doe', 'username': 'j_doe', 'userid': 1, 'fname': 'jane'}
+ john doe = {'lname': 'doe', 'username': 'johnd', 'userid': 2, 'fname': 'john'}
+ willem doe = {'lname': 'doe', 'username': 'w_doe', 'userid': 3, 'fname': 'willem'}
(3 rows)
select nested_call_one('pass this along');
---(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
Kurt Roeckx wrote: On Thu, Jan 30, 2003 at 02:39:59PM -0800, Kevin Brown wrote: With this I agree, but before you start thinking that Windows is the only OS that qualifies, consider this: I've run the pull the plug test under early Linux 2.4 kernels running with ReiserFS. I'd start a make of a large project, pull the power, bring the system back up, and restart the build. And the end result was that some of the files files in the build directory were corrupted, such that the build could not continue. Afaik, ReiserFS does not guarantee data consistency, only meta data. As in, the file system itself will be consistent, and an fsck shouldn't find a problem. Exactly. Does NTFS? Not as far as I know. Why should we hold NTFS to a standard that ReiserFS doesn't meet? That said, I do agree with Tom that the Windows port is basically virgin territory and needs to be approached with caution. But we shouldn't be so cautious that we hesitate to release the port to the world (sufficient disclaimers are appropriate, as with any new port)... -- Kevin Brown [EMAIL PROTECTED] ---(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
Lamar Owen [EMAIL PROTECTED] writes: On Thursday 30 January 2003 16:54, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: And, by the way, who in their right mind tests a database server by repeated yanking of the AC power? Anybody who would like their data to survive a power outage. I don't buy that. That's why I have $36,000 worth of lead acid in the room next door, with $5,000 of inverters and chargers in the server room. Well, great; you're probably proof against misfeasance of your local power company. But how about someone tripping over the power cord? Or a blowout in the server's internal power supply? Or a kernel crash? Pulling the power plug is just a convenient way of (approximately) modeling a whole class of unpleasant events. I don't think the fact that you can afford to spend that much on batteries makes it uninteresting to test such scenarios. But we're pretty much talking at cross-purposes here. The real issue IMHO is that the Windows port needs a lot of testing because it is a new platform (for us), and one not like the platforms we've used before. It is faulty to equate the amount of testing required to gain confidence in that port with the amount of testing required to gain confidence that PG 7.4 will run reliably on, say, HPUX 10.20, when we already know that every PG back to 6.4 has run reliably on HPUX 10.20. You're attacking a straw man you have set up, namely the idea that only specific testing produces confidence in a port. In my mind past track record has a lot more to do with confidence than whatever testing we do for an individual release. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [mail] Re: [HACKERS] Windows Build System
On Thursday 30 January 2003 18:39, Tom Lane wrote: Well, great; you're probably proof against misfeasance of your local power company. But how about someone tripping over the power cord? Twistlok. Or a blowout in the server's internal power supply? Redundant supplies. Or a kernel crash? Different from pulling the plug. It is faulty to equate the amount of testing required to gain confidence in that port with the amount of testing required to gain confidence that PG 7.4 will run reliably on, say, HPUX 10.20, when we already know that every PG back to 6.4 has run reliably on HPUX 10.20. But does the fact that PG 6.4 ran reliably on HP-UX 10 mean PG 7.4 will run as reliably on HP-UX 11? Does the fact that PG 6.2.1 ran well on Linux kernel 2.0.30 with libc 5.3.12 mean PG 7.4 will run well on Linux 2.6.x with glibc 2.4.x? The OS is also a moving target. Hmph. PG 7.3 won't even build on Red Hat 5.2, for instance. So much for track record. You're attacking a straw man you have set up, namely the idea that only specific testing produces confidence in a port. In my mind past track record has a lot more to do with confidence than whatever testing we do for an individual release. Track record means nothing if sufficient items have changed in the underlying OS. I remember the Linux fiasco with PostgreSQL 6.3.1. It was so bad that Red Hat was considering releasing Red Hat 5.1 with a CVS checkout of pre-6.3.2. That is not Red Hat's normal policy. Also, between major versions enough may have changed to make it necessary to test thoroughly -- WAL, for instance. MVCC for another instance. PITR is going to be another instance requiring a different test methodology. One will indeed be required to blow down the whole system to properly test PITR, on all platforms. Track record indicates that all of our x.y.1 releases are typically hosed in some fashion. 7.3.1 proved that wrong. Track record only requires a single failure to invalidate -- and we should test for those failures across the board, regardless of track record. Records are meant to be broken. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] v7.2.4 bundled ...
Kevin Brown [EMAIL PROTECTED] writes: I think it's best to leave well enough alone. The tarball ships with working bison output files anyway, so all of this really only matters to people trying to build 7.2.* from a CVS pull. Okay, fair enough, but if we intend to continue to maintain 7.2.*, shouldn't we at least fix the .y files? What for? If you've bought the assumption that we aren't going to port 7.2's grammar forward indefinitely, why shouldn't we say it stops with bison 1.35 rather than 1.75? 1.75 and later are not widely deployed anyway, as yet. But the more compelling point is *it does not matter* to our customers, and only barely to us. No one but a very few developers will ever again build the .y output files for 7.2.* (even assuming that there are more 7.2.* releases, which I doubt). Doesn't seem worth expending any effort on, to me. We have other, more productive things to do ... 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: [HACKERS] Linux.conf.au 2003 Report
On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote: Also, what are the implications to functions such as network_sub, network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the two are freely mixed in the same data type? 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. Some thing you also shouldn't forget for ipv6 addresses is the scope. An address with a scope of the link can be assigned to several interfaces. If they want to differentiate between them, should they be able to store it the same field, or use a different one? My question really is how you're going to store it. Are you going to store is as a character string, or as binary? If you store is as binary, how will you know if it's an ipv4 or ipv6 address? Based on the size? From an application point of view it's more handy if you have a combination of the address family and the data, so they don't have to guess all the time. P.S.: I don't really like the ipv6 patch. It's more complicated than it should be. I really don't have the time to fix it/do it better though. Kurt ---(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, 30 Jan 2003, Andrew Sullivan wrote: Given that IPv6 is supposed to allow co-operation with IPv4, it seems it'd be pretty hard to force such a view on every application using IP addresses. DNS, for instance. 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. All that said, I'm not advocating separating (or not separating) IPv4 and IPv6 addresses. I'm still undecided on the issue. I can see situations where I might want to store both together, but then again, I can see situations where I certainly wouldn't. Perhaps we should think about another example to try to illuminate this: what about storing ISO/OSI addresses in the same type as well? Isn't that just the same thing as storing IPv4 and IPv6 addresses together? cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Linux.conf.au 2003 Report
On Thu, 30 Jan 2003, Tom Lane wrote: I don't know anything about v6, but I'd imagine v4 addresses form a defined subset of the v6 address space ... No, they do not. The address spaces are completely independent. (There is a compatability space for IPv4 addresses, but it turned out to be impractical, and thus is generally not used. Certainly you cannot route to arbitrary v4 hosts using a v6 address.) cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] v7.2.4 bundled ...
Tom Lane wrote: Kevin Brown [EMAIL PROTECTED] writes: I think it's best to leave well enough alone. The tarball ships with working bison output files anyway, so all of this really only matters to people trying to build 7.2.* from a CVS pull. Okay, fair enough, but if we intend to continue to maintain 7.2.*, shouldn't we at least fix the .y files? What for? If you've bought the assumption that we aren't going to port 7.2's grammar forward indefinitely, why shouldn't we say it stops with bison 1.35 rather than 1.75? 1.75 and later are not widely deployed anyway, as yet. Okay, fair enough. I'll take your word for this (no idea how to determine how widely bison 1.75 and later are deployed). But the more compelling point is *it does not matter* to our customers, and only barely to us. No one but a very few developers will ever again build the .y output files for 7.2.* (even assuming that there are more 7.2.* releases, which I doubt). Doesn't seem worth expending any effort on, to me. We have other, more productive things to do ... Agreed. I wasn't aware, previously, that our source distributions shipped with .c files generated from the .y files. That said, if the parser's gram.y file is anything to go by, the fixes to make it work with bison 1.75 are trivial, so if you change your mind I'll be happy to do the work. -- Kevin Brown [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
[HACKERS] On file locking
I've been looking at the PID file creation mechanism we currently use. It goes through a loop in an attempt to create the PID file, and if one is there it attempts to remove it if the PID it contains no longer exists (there are checks for shared memory usage as well). This could be cleaned up rather dramatically if we were to use one of the file locking primitives supplied by the OS to grab an exclusive lock on the file, and the upside is that, when the locking code is used, the postmaster would *know* whether or not there's another postmaster running, but the price for that is that we'd have to eat a file descriptor (closing the file means losing the lock), and we'd still have to retain the old code anyway in the event that there is no suitable file locking mechanism to use on the platform in question. The first question for the group is: is it worth doing that? The second question for the group is: if we do indeed decide to do file locking in that manner, what *other* applications of the OS-level file locking mechanism will we have? Some of them allow you to lock sections of a file, for instance, while others apply a lock on the entire file. It's not clear to me that the former will be available on all the platforms we're interested in, so locking the entire file is probably the only thing we can really count on (and keep in mind that even if an API to lock sections of a file is available, it may well be that it's implemented by locking the entire file anyway). What I had in mind was implementation of a file locking function that would take a file descriptor and a file range. If the underlying OS mechanism supported it, it would lock that range. The interesting case is when the underlying OS mechanism did *not* support it. Would it be more useful in that case to return an error indication? Would it be more useful to simply lock the entire file? If no underlying file locking mechanism is available, it seems obvious to me that the function would have to always return an error. Thoughts? -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] On file locking
Mmy problem is freebsd getting totally loaded at which point it sends kills to various processes. This sometime seems to end up with several actual postmasters running, and none of them working. Better existing process detection would help that greatly I'm sure. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Brown Sent: Friday, 31 January 2003 11:24 AM To: PostgreSQL Development Subject: [HACKERS] On file locking I've been looking at the PID file creation mechanism we currently use. It goes through a loop in an attempt to create the PID file, and if one is there it attempts to remove it if the PID it contains no longer exists (there are checks for shared memory usage as well). This could be cleaned up rather dramatically if we were to use one of the file locking primitives supplied by the OS to grab an exclusive lock on the file, and the upside is that, when the locking code is used, the postmaster would *know* whether or not there's another postmaster running, but the price for that is that we'd have to eat a file descriptor (closing the file means losing the lock), and we'd still have to retain the old code anyway in the event that there is no suitable file locking mechanism to use on the platform in question. The first question for the group is: is it worth doing that? The second question for the group is: if we do indeed decide to do file locking in that manner, what *other* applications of the OS-level file locking mechanism will we have? Some of them allow you to lock sections of a file, for instance, while others apply a lock on the entire file. It's not clear to me that the former will be available on all the platforms we're interested in, so locking the entire file is probably the only thing we can really count on (and keep in mind that even if an API to lock sections of a file is available, it may well be that it's implemented by locking the entire file anyway). What I had in mind was implementation of a file locking function that would take a file descriptor and a file range. If the underlying OS mechanism supported it, it would lock that range. The interesting case is when the underlying OS mechanism did *not* support it. Would it be more useful in that case to return an error indication? Would it be more useful to simply lock the entire file? If no underlying file locking mechanism is available, it seems obvious to me that the function would have to always return an error. Thoughts? -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] On file locking
file descriptor (closing the file means losing the lock), and we'd still have to retain the old code anyway in the event that there is no suitable file locking mechanism to use on the platform in question. What is the gain given the above statement? If what we currently do can cause issues (fail), then beefing it up where available may be useful -- but otherwise it's just additional code. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] On file locking
Kevin Brown [EMAIL PROTECTED] writes: This could be cleaned up rather dramatically if we were to use one of the file locking primitives supplied by the OS to grab an exclusive lock on the file, and the upside is that, when the locking code is used, the postmaster would *know* whether or not there's another postmaster running, but the price for that is that we'd have to eat a file descriptor (closing the file means losing the lock), Yeah, I was just thinking about that this morning. Eating one file descriptor in the postmaster is absolutely no problem --- the postmaster doesn't have all that many files open anyhow. What I was wondering was whether it was worth eating an FD for every backend process, by holding open the file inherited from the postmaster. If we did that, we would have a reliable way of detecting that the old postmaster died but left surviving child backends. (As I mentioned in a nearby flamefest, the existing interlock for this situation strikes me as mighty fragile.) 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?? The second question for the group is: if we do indeed decide to do file locking in that manner, what *other* applications of the OS-level file locking mechanism will we have? I can't see any use in partial-file locks for us, and would not want to design an internal API that expects them to work. 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
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. And what about MySQL? What about it? Someone claimed in this thread that MySQL's Windows port requires Cygwin. Is that true or not? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [mail] Re: [HACKERS] Windows Build System
Kevin Brown wrote: Greg Copeland wrote: On Thu, 2003-01-30 at 13:56, Dave Page wrote: When properly configured, Windows can be reliable, maybe not as much as Solaris or HPUX but certainly some releases of Linux (which I use as well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable enough. I'm not jumping on one side or the other but I wanted to make clear on something. The fact that IBM or Oracle use windows has absolutely zero to do with reliability or stability. They are there because the market is willing to spend money on their product. Let's face it, the share holders of each respective company would come unglued if the largest software audience in the world were completely ignored. Simple fact is, your example really is pretty far off from supporting any view. Bluntly stated, both are in that market because they want to make money; they're even obligated to do so. That's true, but it ignores the question that makes it relevant: has their appearance in the Windows market tarnished their reputation? More precisely, has it tarnished their reputation in the *Unix* community? The answer, I think, is no. And that *is* relevant to us, because our concern is about the reputation of PostgreSQL, and what will happen to it if we release a native Windows port to the world. More to the point, does the unreliable Cygwin port possibly do our reputation any good? It is known to crash with corruptions under less than heavy load. 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. Anyone here who likes the Cygwin port or can we yank it out right now? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] On file locking
This could be cleaned up rather dramatically if we were to use one of the file locking primitives supplied by the OS to grab an exclusive lock on the file, ... ... The first question for the group is: is it worth doing that? In the past it has been proposed and declined -- there is some stuff in the archives. While it would be beneficial to installations using local data it would introduce new failure modes for installations using NFS. Regards, Giles ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [mail] Re: [HACKERS] Windows Build System
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 30 January 2003 15:56 To: Hannu Krosing Cc: Vince Vielhaber; Dave Page; Ron Mayer; [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Windows Build System In the pull-the-plug case you have to worry about what is on disk at any given instant and whether you can make all the bits on disk consistent again. (And also about whether your filesystem can perform the equivalent exercise for its own metadata; which is why we are questioning Windows here. I've never (to my knowledge) lost any data following a powerfail or system crash on a system using NTFS - that has always seemed pretty solid to me. By comparison, I have lost data on ext2 filesystems on a couple of occasions. More info at: http://www.ntfs.com/data-integrity.htm http://www.pcguide.com/ref/hdd/file/ntfs/relRec-c.html Obviously this goes out of the window is the user chooses to run on FAT/FAT32 partitions. I think that it should be made *very* clear in any future documentation that the user is strongly advised to use only NTFS filesystems. I realise this is not proof that it actually works of course... 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
Lamar Owen [EMAIL PROTECTED] writes: And, by the way, who in their right mind tests a database server by repeated yanking of the AC power? Anybody who would like their data to survive a power outage. To go to that extreme for Win32 when we caution against something as mundane as a kill -9 of postmaster on Unix is absurd. And, yes, I know the difference. I also know that the AC power pull has nothing to do with PostgreSQL, but it has to do with the OS under it. Although a kill -9, from the point of view of the running process, is identical to a power failure. No, it is not. Did you not read my comments earlier today? The reasons why we are concerned about kill -9 have *nothing* to do with whether the database can survive system crashes. Rather, the issues created by kill -9 have to do with coping with leftover state from a previous postmaster in the same system lifecycle. I forgot to mention one of the biggest headaches, which is that kill -9 the postmaster doesn't kill the child backends. We've got an interlock that tries to prevent starting a new postmaster when there are still old children around, but it's one of the things that I think is most likely to break on any new port. (And I'm dead certain that that code doesn't work on Windows.) It's that sort of thing that we have painfully worked out on Unix-based systems, and are going to have to do over again for Windows. In many places we are probably not even going to realize that we have to do something over again, until someone gets bitten. The fact that Postgres is reliable does not come (only) from the code being right in some abstract sense that will carry over to a new platform. A big reason it's reliable is that we have painfully learned about Unix-ish failure modes and put in defenses against them. Windows is going to bring a whole new set of failure modes that we don't have defenses for. (Yet.) *That* is what we need extensive testing to learn about, and claiming that we are discriminating against Windows just because it's Windows misses the point completely. Or, if you prefer, we can ship Postgres 7.4 for Windows with no more testing than we need for any of the existing, long-since-well-tested ports. But I'll bet a great deal that our reputation will go down the drain (along with many people's data) if we do that. 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: [HACKERS] Windows Build System - My final thoughts
Vince Vielhaber [EMAIL PROTECTED] writes: 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. That was my last point also: we have years of track record on most of our Unix ports, and none yet on Windows. Even several months of intensive testing by a small number of people will hardly level the playing field. After that, what about keeping the code current? I don't think that's an issue. We are not blessing anything based on 7.2 ;-). The objective is to merge the changes into CVS tip and have a first official Windows port as part of the 7.4 release. After that, it'll stay as current as any other port that's being actively used. 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
Dave Page [EMAIL PROTECTED] writes: I've never (to my knowledge) lost any data following a powerfail or system crash on a system using NTFS ... Obviously this goes out of the window is the user chooses to run on FAT/FAT32 partitions. I think that it should be made *very* clear in any future documentation that the user is strongly advised to use only NTFS filesystems. This is exactly the kind of thing we have to learn about and document. Which Windows releases can be trusted, which filesystems are okay, what other stuff do you need to stay away from? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL, NetBSD and NFS
Greg Copeland [EMAIL PROTECTED] writes: 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. Whether the thing is trustworthy is a different issue ;-). I was just surprised that it didn't seem to work at all. In practice, if the NFS server never goes down then you probably haven't got a problem. I'm not sure you could count on the database not getting scrambled if the NFS server crashes. But that wasn't the question... 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
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.
Claiming that it doesn't require an increased level of testing is
somewhere between ridiculous and irresponsible.
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 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 :-(
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.
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
On Thu, 2003-01-30 at 13:56, Dave Page wrote: When properly configured, Windows can be reliable, maybe not as much as Solaris or HPUX but certainly some releases of Linux (which I use as well). You don't see Oracle or IBM avoiding Windows 'cos it isn't stable enough. I'm not jumping on one side or the other but I wanted to make clear on something. The fact that IBM or Oracle use windows has absolutely zero to do with reliability or stability. They are there because the market is willing to spend money on their product. Let's face it, the share holders of each respective company would come unglued if the largest software audience in the world were completely ignored. Simple fact is, your example really is pretty far off from supporting any view. Bluntly stated, both are in that market because they want to make money; they're even obligated to do so. -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL, NetBSD and NFS
--On Thursday, January 30, 2003 16:02:17 -0500 Tom Lane [EMAIL PROTECTED] wrote: Greg Copeland [EMAIL PROTECTED] writes: 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. Whether the thing is trustworthy is a different issue ;-). I was just surprised that it didn't seem to work at all. In practice, if the NFS server never goes down then you probably haven't got a problem. I'm not sure you could count on the database not getting scrambled if the NFS server crashes. But that wasn't the question... FWIW I use a netapp filer for my databases here for traffic analysis and IP management. The NETAPP has battery backed NVRAM and will replay the right stuff on it's own. Just another datapoint. LER 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]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [mail] Re: [HACKERS] Windows Build System
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 30, 2003 12:30 PM
To: Lamar Owen
Cc: Dave Page; Vince Vielhaber; Ron Mayer;
[EMAIL PROTECTED]
Subject: Re: [mail] Re: [HACKERS] Windows Build System
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. Claiming that it doesn't require an
increased level of testing is somewhere between ridiculous
and irresponsible.
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 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 :-(
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.
Our port of 7.1.3 passed every test, including the dynamic loading.
I don't expect the Win32 port to be problematic.
---(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 14:27, Dave Page wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 30 January 2003 15:56 To: Hannu Krosing Cc: Vince Vielhaber; Dave Page; Ron Mayer; [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Windows Build System In the pull-the-plug case you have to worry about what is on disk at any given instant and whether you can make all the bits on disk consistent again. (And also about whether your filesystem can perform the equivalent exercise for its own metadata; which is why we are questioning Windows here. I've never (to my knowledge) lost any data following a powerfail or system crash on a system using NTFS - that has always seemed pretty solid to me. By comparison, I have lost data on ext2 filesystems on a couple of occasions. More info at: http://www.ntfs.com/data-integrity.htm http://www.pcguide.com/ref/hdd/file/ntfs/relRec-c.html Obviously this goes out of the window is the user chooses to run on FAT/FAT32 partitions. I think that it should be made *very* clear in any future documentation that the user is strongly advised to use only NTFS filesystems. I realise this is not proof that it actually works of course... 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! I would also like to point out that this damage/repair occurred on a RAID-5 box (hardware, not software). As the repairs placed the file system back into known good state, the raid hardware was happy to obey. Guess what, it did! :( Make no mistake about it. You can easily lose large amounts of data on NTFS. 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. -- 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: [mail] Re: [HACKERS] Windows Build System
On Thursday 30 January 2003 15: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 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. Claiming that it doesn't require an increased level of testing is somewhere between ridiculous and irresponsible. I am saying that as we mature we need increased testing across the board. And it is a very low percentage of code that is tied into the OS API, right? The majority of the code (the vast majority) isn't touched by it. 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 :-( Reread my statement above. I _agree_ with the rationale -- but I fear it will have the opposite impact. And I am not convinced that just because we have good history with the unixoid ports means that we can slack on them -- Linux, *BSD, etc all change. The strftime(3) breakage with RedHat of a cycle ago should show us that much. I suspect there will be problems on Win32 -- it is, after all, a new port. But if we're going to immediately throw pathological test cases at it that we're not even bothering to test against now, that immediately throws up a flag to me. And TESTING IS BEING DONE on the Win32 port, nobody is yet trying to put the PGDG blessing on it as yet, and progress is being made by those who wish to see it made. It is still being touted as beta software, right? The patches from Jan are very preliminary still, correct? Katie hasn't issued a press release saying that it's not beta, right? hyperbole I don't see what the uproar is about, other than 'Win32 is so unstable that it can't possibly work as well as you are seeing it work -- you must be doing something wrong. Test it harder. Pull the plug repeatedly!! Test it until it breaks! HA! Told you it would break! (yeah, firing up the old oxyacetlyene torch and hitting the hard drive with a 6,000 degree flame did the trick -- this has got to be a bad operating system!)' /hyperbole And, by the way, who in their right mind tests a database server by repeated yanking of the AC power? To go to that extreme for Win32 when we caution against something as mundane as a kill -9 of postmaster on Unix is absurd. And, yes, I know the difference. I also know that the AC power pull has nothing to do with PostgreSQL, but it has to do with the OS under it. Although a kill -9, from the point of view of the running process, is identical to a power failure. It simply dies (unless it becomes a zombie, in which case it is undead) either way. The effects of a kill -9 shouldn't be as severe as a power fail, since the OS can properly flush written buffers even after the process writing them has died. And I also can point the finger at some Unix swervers (spelling intentional) that would fail that test in a miserable way. I can also point at a few VMS machines that couldn't pass that test. I've even seen machines blow up due to improper power cycling. And I've seen Win2k machines come right up after repeated power blips (I've also seen them not come up). It really depends upon what the hard disk is doing at the instant the regulators drop out the 5 and 12V supplies (and which supply goes out first, which can depend upon the respective loads -- for modern Pentium 4 systems the 12V will probably go down first since it is more heavily loaded than the 5V supply in these systems). Under certain conditions where the 12V goes down before the 5V does, the head might still be writing as the servo spirals towards park, causing all manner of damage (maybe even to servo information, which normally cannot be written). So the power cycle becomes a test of hardware, too, played Russian Roulette-style. Talk about an unscientific test. A database server that needs that kind of testing is going to be hardened hardware on a doubly redundant UPS anyway. But, then again I've seen a Linux server survive a power cycle with no lost data (ext3 filesystem -- I've seen lost data with ext2). And I've seen the same server barf all over itself due to a single bit error in memory. Blew out the entire root filesystem, which was journaled and residing on a RAID 1 partition (the corruption was perfectly mirrored, by the way). Serves me right for not having ECC RAM installed at the time. 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. I fully expect that Katie, Jan, Dave, and all the others working on this share your concerns and want the Win32 port to be as solid as is possible on that OS. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Windows Build System - My final thoughts
On Thursday 30 January 2003 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. 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). For the record, again, I am not at all in favor of a Win32 native port. I have never been in favor of a Win32 native port (see the archives -- it's in there). I am in favor of fair testing for all ports, and less of an emotional response to the idea of a Win32 port. It's going to happen; we can't stop it; we might as well see how best to handle it. And I am definitely not in favor of putting the Royal Seal of PGDG on the code that is out there now. It _isn't_ proven. And, as Tom just said, it's 7.2, and we're not due to make an Officially Stamped Win32 native port until 7.4. But it doesn't take AC power cycling to prove it, either. And so I objected to the tone and to the extremity of the proposed testing, relative to the testing we do now for the other ports. But I also see the futility of withholding the Official Stamp of Approval -- if Win32 PostgreSQL is out there (and it will be, whether we like it or not), then we will get flak over it if it breaks. Logically we should do everything we can to make sure the port is as stable as possible for Win32 -- and power cycle testing ain't the right way. ISTM that Dave, Katie, Jan, et all are doing this. They even seem to know what they are talking about, which is better than most Win32 partisans. There actually _can_ be reasonable people who use an unreasonable OS, for whatever reasons they may have. Do I like it? No. Can I change it? No. Can I help test the Win32 port? Yes, even though I don't want to do so. Can I be reasonable and patient with those who are doing the work on the Win32 port? Yes, I can. Do I need to sling the napalm because I don't like it? Not on the mailing lists (hmm, need to get some naptha, some palmitic acidmight be fun to sling some napalm in the back yard to rid the place of weeds, and get some relaxation to boot). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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 Thursday 30 January 2003 13:34, Tom Lane wrote:
anyone took anything I said as a personal attack. It wasn't meant that
way.
With a flame on tag? Flames are by long tradition personal. But I
understand that that wasn't the intent -- the flame on was more of a
emphasis tag.
Sure, we're on record as not liking Windows. But:
But as to 'industrial strength testing' -- do ANY of our releases get
this sort of testing on ANY platform? No, typically it's 'regression
passed' 'Ok, it's supported on that platform.'
Most variants of Unix are known to be pretty stable. Most variants of
Unix are known to follow the Unix standard semantics for sync() and
fsync(). I think we are entirely justified in doubting whether Windows
is a suitable platform for PG, and in wanting to run tests to find out.
Testing is being done. Those who are testing it are comfortable so far in its
capabilities. We will hear about it, loadly, when that changes, I'm sure.
Yes, we are holding Windows to a higher standard than we would for a
Unix variant.
Which is pretty ironic, given Win's reputation, right?
Partly this is a matter of wanting to protect Postgres' reputation.
And here's where the rubber meets the road. We, like many developers of
software (open source and otherwise) have worked on this for so long and so
hard that we have personified the program and it has become our child, so to
speak. As a father of four, I know what that can do. We will protect our
child at any cost, vehemently so. I for one can recognize this, and further
recognize that _it's_just_a_program_ (!) and not my child. This is hard
to do. We're seeing our child experiment with what we consider to be bad
company, and the defense mechanism is kicking in.
Just on sheer numbers, if there is a native Windows port then there are
likely to be huge numbers of people using Postgres on Windows. If
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. I believe we should test every release as pathologically as Vince
has stated for Win32. The more reliable we become, the worse our test cases
should become. Across the board, and not just on Win32.
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?'). I for one don't want that to be a
conclusion -- but the 'suits' will see it that way, rest assured.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Windows Build System - My final thoughts
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). 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? 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 Thu, 30 Jan 2003, Dave Page wrote: -Original Message- From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] Sent: 30 January 2003 19:20 To: Lamar Owen Cc: Tom Lane; Dave Page; Ron Mayer; [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Windows Build System I've been on both sides know that the windows user/developer doesn't hold things to the same standards as the unix user/developer. 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. Grow up Dave. That shit doesn't belong on this or any other list. If you didn't want to do something, you shouldn't have volunteered to do it. 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 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: Vince Vielhaber [mailto:[EMAIL PROTECTED]] Sent: 30 January 2003 09:17 To: Ron Mayer Cc: [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Windows Build System On Wed, 29 Jan 2003, Ron Mayer wrote: Cool irony in the automated .sig on the mailinglist software... On Wed, 29 Jan 2003, Vince Vielhaber wrote: ... hammering the betas is a far cry from an industrial-strength solution. ... TIP 4: Don't 'kill -9' the postmaster Sounds like you're basically saying is _do_ 'kill -9' the postmaster... and make sure it recovers gracefully when testing for an industrial- strength solution. Not what I said at all. It's not far off, but it's quite amusing none the less. What I read from your postings it that you are demanding more rigourous testing for a new major feature *prior* to it being comitted to CVS in a dev cycle than I think we ever gave any previous new feature even in the beta test phase. I don't object to testing, and have been thinking about coding something to address Tom's concerns, but let's demand heavy testing for the right reasons, not just to try to justify not doing a Win32 port. I would also point out that we already list the Cygwin port of PostgreSQL as supported. Who ever gave that the kind of testing people are demanding now? I think the worst case scenario will be that our Win32 port is far better than the existing 'supported' solution. 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: [mail] Re: [HACKERS] Windows Build System
On Thu, 2003-01-30 at 13:24, Vince Vielhaber wrote: On Thu, 30 Jan 2003, Dave Page wrote: On Wed, 29 Jan 2003, Ron Mayer wrote: Cool irony in the automated .sig on the mailinglist software... On Wed, 29 Jan 2003, Vince Vielhaber wrote: ... hammering the betas is a far cry from an industrial-strength solution. ... TIP 4: Don't 'kill -9' the postmaster Sounds like you're basically saying is _do_ 'kill -9' the postmaster... and make sure it recovers gracefully when testing for an industrial- strength solution. Not what I said at all. It's not far off, but it's quite amusing none the less. I agree with Tom on yanking the plug while it's operating. Do you know the difference between kill -9 and yanking the plug? Kill -9 seems to me _less_ severe than yanking the plug but much easier to automate, so that could be the first thing to test. You have no hope of passing the pull-the-plug test if you can't survive even kill -9. Perhaps we could have a special reliability-regression test that does kill -9 postmaster, repeatedly, at random intervals, and checks for consistency ? Maybe we will find even some options for some OS'es to force-unmount disks. I guess that setting IDE disk's to read-only with hdparm could possibly achieve something like that on Linux. What I read from your postings it that you are demanding more rigourous testing for a new major feature *prior* to it being comitted to CVS in a dev cycle than I think we ever gave any previous new feature even in the beta test phase. I don't object to testing, and have been thinking about coding something to address Tom's concerns, but let's demand heavy testing for the right reasons, not just to try to justify not doing a Win32 port. Nice try. I've demanded nothing, quit twisting my words to fit your argument. If you're going to test and call it conclusive, do some conclusive testing or call it something else. So we have no conclusive testing done that /proves/ postgres to be reliable ? I guess that such thing (positive conclusive reliability test) is impossible even in theory. But Dave has done some testing that could not prove the opposite and concluded that it is good enough for him. So I guess that his test were if fact conclusive, if only just for him ;) Sometimes it is very hard to do the pull-the-plug test - I've seen people pondering over a HP server they could not switch off after accidentally powering it up. Pulling the plug just made it beep, but did not switch it off ;) But I suspect that since you don't know the difference between yanking the plug and kill -9 this conversation is a waste of time. I assume you realize that U can't kill -9 the plug ;) -- 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] Linux.conf.au 2003 Report
[ pgsql-advocacy trimmed from cc list; seems off-topic for them ] D'Arcy J.M. Cain [EMAIL PROTECTED] writes: On Thursday 30 January 2003 07:42, Gavin Sherry wrote: Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra 96 bits of storage?). Use of ipv4 and ipv6 should be mutually exclusive. Extra code in inet type causing bloat. The inet code has been designed from day one to handle ipv6. It was assumed that the extra glue would be added when it was needed. I don't see any reason to change that. I also don't think it adds an extra 12 bytes to ipv4 addresses if you do. The type is variable size if I recall correctly. Yes, it is; so the extra storage argument holds no water. And the code bloat argument doesn't either, that I can see. It's not going to take more code to incorporate ipv6 functionality as part of an existing datatype than as part of a new datatype. (If anything, it should take less code that way; you don't need any extra per-datatype overhead.) Certainly we don't want people to have two different fields for the same piece of information, an IP address. That's the main argument in my mind. If a user *wants* to segregate ipv4 and v6 addresses, he can do so in any case --- but if he'd rather have a column that could be either kind, only the unified-datatype approach will be convenient for him. Why exactly should use of ipv4 and ipv6 be mutually exclusive? I don't see the argument for that. (It'd have to be an argument that doesn't just establish a scenario where you'd want that, but proves that we should force that point of view upon every application using IP addresses.) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] PostgreSQL, NetBSD and NFS
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. Other things continue to run but the minute I do a df or an ls on
that drive that terminal is lost.
On the NetBSD side I get a server not responding error. On the filer I see
no problems at all. A reboot of the filer doesn't correct anything.
Since NetBSD works just fine with this until I start PostgreSQL and
PostgreSQL, from all reports, works well with the NetApp filer, I assume that
there is something out of the ordinary about PostgreSQL's disk access that is
triggering some subtle bug in NetBSD. Does the shared memory stuff use disk
at all? Perhaps that's the difference between PostgreSQL and other
applications.
The NetApp people are being very helpful and are willing to follow up any
leads people might have and may even suggest fixes if necessary. I have
Bcc'd the engineer on this message and will send anything I get to them.
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [mail] Re: [HACKERS] Windows Build System
Hannu Krosing [EMAIL PROTECTED] writes: Kill -9 seems to me _less_ severe than yanking the plug but much easier to automate, so that could be the first thing to test. You have no hope of passing the pull-the-plug test if you can't survive even kill -9. Actually, they're two orthogonal issues. In the pull-the-plug case you have to worry about what is on disk at any given instant and whether you can make all the bits on disk consistent again. (And also about whether your filesystem can perform the equivalent exercise for its own metadata; which is why we are questioning Windows here. Oracle's Windows port may have an advantage, if they bypass the OS to do raw disk I/O as they do on other platforms.) In the kill -9 case there is no risk of losing data consistency on disk, because the OS isn't crashing; whatever we last wrote we can expect to read. The issue for kill -9 is whether we can deal with leftover dynamic state, like pre-existing shared memory segments, pre-existing SysV semaphores, TCP port numbers that the kernel won't reassign until some timeout expires, that kind of fun stuff. 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... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [mail] Re: [HACKERS] Windows Build System
Dave Page [EMAIL PROTECTED] writes: I would also point out that we already list the Cygwin port of PostgreSQL as supported. Who ever gave that the kind of testing people are demanding now? I think the worst case scenario will be that our Win32 port is far better than the existing 'supported' solution. A good point --- but what this is really about is expectations. If we support a native Windows port then people will probably think that it's okay to run production databases on that setup; whereas I doubt many people would think that about the Cygwin-based port. So what we need to know is whether the platform is actually stable enough that that's a reasonable thing to do; so that we can plaster the docs with appropriate disclaimers if necessary. Windows, unlike the other OSes mentioned in this thread, has a long enough and sorry enough track record that it seems appropriate to run such tests ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [mail] Re: [HACKERS] Windows Build System
On Thursday 30 January 2003 11:12, Tom Lane wrote: A good point --- but what this is really about is expectations. If we support a native Windows port then people will probably think that it's okay to run production databases on that setup; whereas I doubt many people would think that about the Cygwin-based port. So what we need to know is whether the platform is actually stable enough that that's a reasonable thing to do; so that we can plaster the docs with appropriate disclaimers if necessary. Windows, unlike the other OSes mentioned in this thread, has a long enough and sorry enough track record that it seems appropriate to run such tests ... I think it's just developer backlash to Win32. I am on record (see the archives) as not wanting the Win32 port -- but the vitriol I've seen in this thread from several people is entirely uncalled for and is sickening. Dave appears to have tested this Win32 beta at least as much as a regular PostgreSQL release would be tested. These tests are being held to artificially high standards, simply because it's native Win32. That is disgusting. And poor Katie just got _slammed_ -- and she's the lead developer. Vince, I would say that we, the developers of PostgreSQL, are then not qualified to test our own releases for the reasons you mentioned that Katie should not test her own releases. Of course that's ridiculous -- often the developers can do a better job of testing because they know better than the regular user would about what conditions can cause crashes. I don't like the thoughts of native Win32 either. I think Win32 should die a long horrible death. But that doesn't give me the right to publicly ridicule the folks that want to use PostgreSQL, even if it's in an 'industrial strength setting,' on Win32. The BSD license indemnifies us anyway. So what's the problem. The developers don't like Win32. That's the problem. But as to 'industrial strength testing' -- do ANY of our releases get this sort of testing on ANY platform? No, typically it's 'regression passed' 'Ok, it's supported on that platform.' -- 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
On Thu, 30 Jan 2003, Lamar Owen wrote: Vince, I would say that we, the developers of PostgreSQL, are then not qualified to test our own releases for the reasons you mentioned that Katie should not test her own releases. Of course that's ridiculous -- often the developers can do a better job of testing because they know better than the regular user would about what conditions can cause crashes. Don't twist what I said. My statement about Katie was that she has a knowledge of the port and the OS to the point where there are things that she knows are wrong to do and would avoid doing it. In the case of this port the idea is to make sure that those things that may cause the backend to close are something that SHOULD be tested. By their own admission they haven't been doing that. All they've done is loaded it down and made sure it continued to work. The other ports have a long history, the windows port has ZERO history. If you're being sickened now, how sick would you be if something went wrong and you started seeing things all over /. and other sites going on about how PG crashed and blew away some corporation's data and half the OS away on something that at worse should have only caused the backend to close? It won't matter that it was running on windows, it would have been a native port that was blessed by the PGDG. If anything, the resistance to this testing should sicken you. 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
Lamar Owen [EMAIL PROTECTED] writes: And poor Katie just got _slammed_ -- and she's the lead developer. We could definitely do without the vitriol. I'd like to apologize if anyone took anything I said as a personal attack. It wasn't meant that way. The developers don't like Win32. That's the problem. Sure, we're on record as not liking Windows. But: But as to 'industrial strength testing' -- do ANY of our releases get this sort of testing on ANY platform? No, typically it's 'regression passed' 'Ok, it's supported on that platform.' Most variants of Unix are known to be pretty stable. Most variants of Unix are known to follow the Unix standard semantics for sync() and fsync(). I think we are entirely justified in doubting whether Windows is a suitable platform for PG, and in wanting to run tests to find out. Yes, we are holding Windows to a higher standard than we would for a Unix variant. Partly this is a matter of wanting to protect Postgres' reputation. Just on sheer numbers, if there is a native Windows port then there are likely to be huge numbers of people using Postgres on Windows. If that's not going to be a reliable combination, we need to know it and tell them so up-front. Otherwise, people will be blaming Postgres, not Windows, when they lose data. It's an entirely different situation from whether Postgres-on-Joe-Blow's-Unix-Variant loses data, first because of visibility, and second because of the different user base. Am I being paranoid to suspect that the average Postgres-on-Windows user will be less clueful than the average Postgres-on-Unix user? I don't think so. Between the population factors and Windows' hard-earned reputation for unreliability, we would be irresponsible not to be asking tough questions here. If the Windows partisans don't think Windows should be held to a higher standard than the platforms we already deal with, why not? Are they afraid that their platform won't pass the scrutiny? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [mail] Re: [HACKERS] Windows Build System
On Thursday 30 January 2003 13:17, Vince Vielhaber wrote: On Thu, 30 Jan 2003, Lamar Owen wrote: Vince, I would say that we, the developers of PostgreSQL, are then not qualified to test our own releases for the reasons you mentioned that Katie should not test her own releases. Don't twist what I said. My statement about Katie was that she has a knowledge of the port and the OS to the point where there are things that she knows are wrong to do and would avoid doing it. Then she would not be honestly testing, would she? admission they haven't been doing that. All they've done is loaded it down and made sure it continued to work. The other ports have a long history, the windows port has ZERO history. Do we do powerfail testing on a unix-type port now? That's not testing the port, incidentally, it's testing the OS, sync semantics aside. Do we hold the other ports to the same standards? Yes, the Win32 port is a substantial change from the Unix ports. Yes, it needs robust testing. But all the ports need that same grade of testing, not just Win32. And that type of testing is not being rigorously done on any port now, unless it is being done by a few that aren't announcing that they are doing it. And thanks to hardware write-back caching on many hard drives, powerfail testing may be moot regardless of OS or filesystem type. If you're being sickened now, how sick would you be if something went wrong and you started seeing things all over /. and other sites going on about how PG crashed and blew away some corporation's data and half the OS away on something that at worse should have only caused the backend to close? Sick enough. But that applies to all our supported platforms, not just Win32. From what I've seen and heard the 'supported' Cygwin port will barf all over itself under high load. So, the first thing I personally would test for a Win32 native port is 'how well is it performing under load?' -- after it passes that I would then throw the more pathological cases at it. It won't matter that it was running on windows, it would have been a native port that was blessed by the PGDG. So? How many users out there actually know about the PGDG? How many users have gotten PostgreSQL from their distributor of choice (whether a Linux distribution, the Cygwin distribution, FreeBSD ports, or wherever) and know nothing of PGDG or even postgresql.org? We make ourselves too important. I know enough to take all those sites with a shakerful of salt. But then again I know enough to know that the batboy didn't help Clinton or Bush do anything, 'Weekly World News' aside. We can't prevent the tabloid mentality regardless of what we do. Or don't do. The point being that if any release of anything labeled 'PostgreSQL', regardless of its status as blessed or not blessed (or even cursed) by the PGDG, does what you've said, PostgreSQL as a whole will suffer. Our blessing or cursing is meaningless to most users. Or, in slightly different words, if they can't be bothered to care that it's on Windows then they aren't going to care whether we gave it the Royal Seal of PGDG either. However, I'm sure the folks that are wanting to sell this Win32 native port care a whole lot about how much return business they get -- so I'm sure they care more about whether it is robustly tested than you give them credit. If anything, the resistance to this testing should sicken you. There isn't any resistance to this testing that I've seen. ISTM that the resistance is to the idea of a 'supported' WIn32 native port. So, let's test the Win32 native beta using your scheme, and see what falls down. And let's test Linux, *BSD, HP-UX, and AIX using the same scheme and see if it falls down. Let's just be fair about the testing. The Win32 stuff is being proclaimed as beta already -- so none are being misled into thinking it's production grade right now. But it is passing those tests that hitherto have been thrown at it -- and it seems to be passing them well. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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
Forgive my stupidity, are you running PostgreSQL with the data on an NFS share? D'Arcy J.M. Cain wrote: 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. Other things continue to run but the minute I do a df or an ls on that drive that terminal is lost. On the NetBSD side I get a server not responding error. On the filer I see no problems at all. A reboot of the filer doesn't correct anything. Since NetBSD works just fine with this until I start PostgreSQL and PostgreSQL, from all reports, works well with the NetApp filer, I assume that there is something out of the ordinary about PostgreSQL's disk access that is triggering some subtle bug in NetBSD. Does the shared memory stuff use disk at all? Perhaps that's the difference between PostgreSQL and other applications. The NetApp people are being very helpful and are willing to follow up any leads people might have and may even suggest fixes if necessary. I have Bcc'd the engineer on this message and will send anything I get to them. ---(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
On Thu, 30 Jan 2003, Lamar Owen wrote: On Thursday 30 January 2003 13:17, Vince Vielhaber wrote: On Thu, 30 Jan 2003, Lamar Owen wrote: Vince, I would say that we, the developers of PostgreSQL, are then not qualified to test our own releases for the reasons you mentioned that Katie should not test her own releases. Don't twist what I said. My statement about Katie was that she has a knowledge of the port and the OS to the point where there are things that she knows are wrong to do and would avoid doing it. Then she would not be honestly testing, would she? She consider herself testing to her own standards as a windows user/ developer. Is that enough? IMO, No. I've been on both sides know that the windows user/developer doesn't hold things to the same standards as the unix user/developer. admission they haven't been doing that. All they've done is loaded it down and made sure it continued to work. The other ports have a long history, the windows port has ZERO history. Do we do powerfail testing on a unix-type port now? That's not testing the port, incidentally, it's testing the OS, sync semantics aside. Do we hold the other ports to the same standards? Yes, the Win32 port is a substantial change from the Unix ports. Yes, it needs robust testing. But all the ports need that same grade of testing, not just Win32. And that type of testing is not being rigorously done on any port now, unless it is being done by a few that aren't announcing that they are doing it. Since you're pretty much ignoring my reasoning, I'll give you the same consideration. The history of windows as a platform has shown itself to be rather fragile compared to unix. Before you respond to this, read Tom Lane's response and reply to that. 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL, NetBSD and NFS
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. Regards, Greg On Thu, 2003-01-30 at 13:02, mlw wrote: Forgive my stupidity, are you running PostgreSQL with the data on an NFS share? D'Arcy J.M. Cain wrote: 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. Other things continue to run but the minute I do a df or an ls on that drive that terminal is lost. On the NetBSD side I get a server not responding error. On the filer I see no problems at all. A reboot of the filer doesn't correct anything. Since NetBSD works just fine with this until I start PostgreSQL and PostgreSQL, from all reports, works well with the NetApp filer, I assume that there is something out of the ordinary about PostgreSQL's disk access that is triggering some subtle bug in NetBSD. Does the shared memory stuff use disk at all? Perhaps that's the difference between PostgreSQL and other applications. The NetApp people are being very helpful and are willing to follow up any leads people might have and may even suggest fixes if necessary. I have Bcc'd the engineer on this message and will send anything I get to them. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Greg Copeland [EMAIL PROTECTED] Copeland Computer Consulting ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
Dave Page wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: 29 January 2003 16:57 To: Dave Page Cc: Vince Vielhaber; Katie Ward; Curtis Faith; [EMAIL PROTECTED] Subject: Re: [mail] Re: [HACKERS] Windows Build System Dave Page [EMAIL PROTECTED] writes: I'll admit my methods were not particularly scientific, but over the last few weeks I've had far more grief from DB2 and SQL Server than I did from the PostgreSQL native betas. My gripe had to do with questioning the reliability of the platform, not of the Postgres port ;-). Aside from load testing as suggested by Vince, I'd be interested to hear what happens when you pull the power cord under load (repeatedly). This would give some evidence about the robustness of the Windows filesystem and its ability to emulate Unix sync semantics. OK, I can maybe do some testing on that next week (I'm off for a few days from today). Is there anything in particular I should look out for, or that you would want tested? Katie, can I get the latest build from anywhere? The code Katie wrote and tested, and what has been posted by me are two different things. So what has been posted might not be that solid as a rock as the beta's you got from PeerDirect. I will try to put some binaries of what I posted together over the weekend. That said, I don't quite understand the attitude of some people here. Is it that if the native Win32 port as I posted it isn't as solid and stable as v7.3 on Unix (well, some flavours), we will have to reject it? With that ruleset (ruleset, what a word in this context ;-) we would not have an SQL parser yet ... Also, so far I have the impression not many people have actually taken a look at the code itself. Everyone is busy bitching about the build environment and if it is kosher to cook the code in Cygwin milk on a Microsoft stove or not. Sorry guy's, but that's not the point! Does anyone feel that the quality of our mainstream unix product is in serious danger because of the code changes, required for the Win32 port, which affect the unix environment? If so, could those please discuss their feelings with their spouses or shrinks unless they can actually point at specific areas of the code? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [mail] Re: [HACKERS] Windows Build System
Katie Ward wrote: The latest build is still: ftp://209.61.187.152/postgres/postgres_beta4.zip This is not exactly what Jan submitted, and the catalog number is slightly different, but it should do for testing. That binary at least demonstrates, what could be built based on the code submitted. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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: Most variants of Unix are known to be pretty stable. Most variants of Unix are known to follow the Unix standard semantics for sync() and fsync(). I think we are entirely justified in doubting whether Windows is a suitable platform for PG, and in wanting to run tests to find out. Yes, we are holding Windows to a higher standard than we would for a Unix variant. Partly this is a matter of wanting to protect Postgres' reputation. Just on sheer numbers, if there is a native Windows port then there are likely to be huge numbers of people using Postgres on Windows. If that's not going to be a reliable combination, we need to know it and tell them so up-front. Otherwise, people will be blaming Postgres, not Windows, when they lose data. It's an entirely different situation from whether Postgres-on-Joe-Blow's-Unix-Variant loses data, first because of visibility, and second because of the different user base. Am I being paranoid to suspect that the average Postgres-on-Windows user will be less clueful than the average Postgres-on-Unix user? I don't think so. Assuming all your assumptions are right, why the hell is Oracle's and MS SQL-Server's reputation that bloody good? And what about MySQL? They all have a native Windows (sup)port for some time ... didn't harm their reputation. I think that we got in bed with this ugly Cybill ... er ... Cygwin thing had cost us more reputation than the sucking performance of pre-7 releases all together. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL, NetBSD and NFS
On Thu, 30 Jan 2003, D'Arcy J.M. Cain wrote: Does the shared memory stuff use disk at all? Perhaps that's the difference between PostgreSQL and other applications. Shared memory in NetBSD is just an interface to mmap'd pages, so it can be swapped to disk. But I assume your swap is not on NFS A ktrace would be helpful. Also, it would be helpful if you tried doing an initdb to a directory on the filer to see if you can even create a database cluster, and tried doing that or rsyncing and accessing your data over NFS with a NetBSD system as the NFS server. 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
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: And, by the way, who in their right mind tests a database server by repeated yanking of the AC power? Anybody who would like their data to survive a power outage. ... has UPS, ECC Ram on quality boards and storage subsystems that guarantee the data to hit some surface after it passed the interface ... what's your point? Are you telling me that the reliability of an EMC2 system depends on which OS it is receiving the bits from? Is SuSE as reliable as TurboLinux? Or do I have to buy AIX to get the best result? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [mail] Re: [HACKERS] Windows Build System
Hannu Krosing wrote: I agree with Tom on yanking the plug while it's operating. Do you know the difference between kill -9 and yanking the plug? Kill -9 seems to me _less_ severe than yanking the plug but much easier to automate, so that could be the first thing to test. You have no hope of passing the pull-the-plug test if you can't survive even kill -9. Perhaps we could have a special reliability-regression test that does kill -9 postmaster, repeatedly, at random intervals, and checks for consistency ? Maybe we will find even some options for some OS'es to force-unmount disks. I guess that setting IDE disk's to read-only with hdparm could possibly achieve something like that on Linux. Get VMWare for Linux, run whatever OS you like in it and kill -9 the virtual machine. That's as close as you can get to yanking without wearing out your power plugs. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Request for qualified column names
Peter Eisentraut wrote: Dave Cramer writes: The method in question is ResultSetMetaDate.getTableName(int column) and while were at it ResultSetMetaData.getSchemaName(int column) and FWIW, the return value if not applicable is Not applicable sounds fine to me. It's like taking a file descriptor and asking what file it belongs to. That information simply doesn't exist, and if you design an application around it you lose. Yes, but in cases we can supply the info with the proper GUC variable enabled, why not do it? I realize most people don't want it, but if jdbc does, and it is something folks would use, maybe we should enable it for the easy cases. However, the number of cases where we would not be able to easily report it may make the feature useless. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] postgres installation - best configuration?
Also, I have heard a lot of people reocommending RAID 0+1 or 1+0 as a good mix of reliability and performance. --- Curt Sampson wrote: On Thu, 23 Jan 2003, David Kennedy wrote: This weekend I will be building a couple of new postgres database servers under RH7.3, and I am currently deciding between 2 different configuration options. The new servers feature hot-swappable RAID w/ 3 hard drives in each. It depends on what you need in terms of reliability and performance. Best performance (assuming non-insignifcant write load): Put the OS and DB on the first two drives, striped (RAID0), and the logs on the third drive. Best safety maximum capacity: Put everything on a single RAID5 across all three drives. (RAID5 on three drives is likely to be significantly slower than a single disk or mirrored pair would be, though.) Best safety with good performance: Mirror two drives (RAID1) and put everything on the pair. Use the third drive as a hot spare for the mirrored pair. cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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: [HACKERS] postgres installation - best configuration?
On Fri, 31 Jan 2003, Bruce Momjian wrote: Also, I have heard a lot of people reocommending RAID 0+1 or 1+0 as a good mix of reliability and performance. Right. Striping across mirrored drives will definitely be better, but you can't do that with only three drives. 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
