Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
Tom Lane <[EMAIL PROTECTED]> writes: > >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops); > >> + ERROR: cannot read block 3 of hash_i4_index: Bad address > > "Bad address"? That seems pretty bizarre. This is obviously something that shows up on _some_ NetBSD platforms. The above was on sparc64, but that same problem is the only one I see in the regression testing on NetBSD/vax that isn't just different floating point (the VAX doesn't have IEEE), different ordering of (unordered) collections or different wording of strerror() output. NetBSD/i386 doesn't have the "Bad address" problem. -tih -- The basic difference is this: hackers build things, crackers break them. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
AW: [HACKERS] ecpg long int problem on alpha + fix
> > Could you please try to just remove the cpp flag? Also I wonder why you are > > using "long long int" instead of just "long int" in your C program. Well > > that is the people who complained to you. > > Yes, dropping the CPP flags solves the problem for us. I assume all > platforms have long long now? > > We used long long as this seems to be pretty consistently 64 bits on > different platforms, and our code runs on Tru64, PC linux and openBSD. I think the people did the perfectly correct thing to use long long int, since that makes their code more portable. Can someone try to help me understand this please ? My understanding so far is: 1. long int is the same as long (32 or more bits) 2. long long int is at least 64 bits (I have so far not seen more that 64 bits) (my original understanding was that it is 64bits, but Tom corrected me) So my conclusion would be, that ecpg should understand "long long int" since that is preferable over a "long int" that is 64bits by chance. I do agree with the statement, that HAVE_LONG_LONG_INT_64 shoud be defined on all platforms where the compiler understands it to be 64bits. It would imho be the responsibility of backend code, to only do one of the two if both are defined. Otherwise the defines should have a different name like USE_ Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] ecpg long int problem on alpha + fix
On Thu, Apr 05, 2001 at 09:13:49AM +0300, Adriaan Joubert wrote: > I think we probably do need the CPP defines from my patch in there, so Not exactly. The test in typename.c does not make sense at all. It will be removed. But there are other places where it is needed. Or can I safely assume that if HAVE_LONG_INT_64 is defined then HAVE_LONG_LONG_INT_64 also is true, although not defined? Hmm, thinking about it, how about using long instead of long long if HAVE_LONG_LONG_INT_64 is undefined? Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] ecpg long int problem on alpha + fix
On Thu, Apr 05, 2001 at 10:01:53AM +0200, Zeugswetter Andreas SB wrote: > I do agree with the statement, that HAVE_LONG_LONG_INT_64 shoud be > defined on all platforms where the compiler understands it to be 64bits. > It would imho be the responsibility of backend code, to only do one of > the two if both are defined. I just committed some changes so that ecpg does acceptt "long long" variables all the time, but repleces them with type "long" if HAVE_LONG_LONG_INT_64 is not defined. This appears to be a strategy similar to the one used by the backend. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] RE: [BUGS] Loosing files after backend crash
> > FATAL 2: XLogWrite: write request is past end of log" to syslog. Ok, I hope this one is fixed. Tom, please review changes. Konstantin, are you able to compile PG from CVS? To restart postmaster with current version... Vadim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configure problems on Solaris 2.7, pgsql 7.02 and 7.03
Mathijs Brands wrote: > > On Wed, Apr 04, 2001 at 06:46:12PM +0300, Martín Marqués allegedly wrote: > > Why are you running configure inside src/? I'm not sure if the 7.0.x had the > > configure on the src/ dir or the root. > > It's in the src dir with 7.0.x alright. > > > You could take a look at 7.1RC[2-3], which looks pretty stable, and I have > > (RC1) compiled and working on a Solaris 8 SPARC. > > I'm using pgsql 7.0.3 on Solaris 7 Sparc and Solaris 8 Intel for a > website that get's about 600,000 pageviews daily. pgsql 7.0.x works > without problems for me and I'm connecting to it via JDBC. No crashes > or major problems so far. > This is pretty much what I want to do - it is an internal management server but the principle is the same and I intend to use JDBC to connect to it. I'm glad to hear you are getting good results. Anyway, I checked out 7.1RC2 and it configured OK, but gave me an error on make, in an include file. We are planning the first release of the management system for August, so it would be preferable to get a stable system up and running ASAP rather than a test one. > Anyway, 7.0.x should work problem free on Solaris (there are some > issues with 7.1 at the moment). To make this a bit easier to diagnose, > could you send me the output of the following commands? > Here they are, with a couple extra for luck. The obese path is the creation of the sysadmins here, and I have had to install my own versions of make and sed: ## eeiatuc282 eeicjon 101> uname -a SunOS eeiatuc282 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-5_10 eeiatuc282 eeicjon 102> echo $PATH /client_local/db/ant/bin:/client_local/mysql-3.22.32-sun-solaris2.7-sparc/bin:/home/eeicjon/R7B/bin:/apps/Java/jdk1.2.2_05/bin:/apps/workshop/SUNWspro/bin/:/usr/ccs/bin:/home/atus07B/apps3/emacs-20.5/bin:/usr/atria/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/usr/bin:/usr/ucb:/usr/lib/X11:/usr/local/SUNWspro:/usr/openwin/lib/X11:/usr/bin:/bin:/usr/etc:/usr/5bin:/usr/sbin:/usr/local/bin:/usr/ucb:/usr/local/flextool/bin/sun4:/usr/openwin/bin:/usr/openwin/bin/xview:/home/atus07C/apps4/apssystem_v3.2/bin:/apps/localtools/filediff:/apps/scripts:/apps/localtools:/usr/local/WWW/bin:/home/atus02A/publish/ioffice/bin:/home/atus11B/SUNWspro/bin:/apps/Java/jdk1.1/bin:/apps/Java/jdk1.2beta3:/apps/Java/jit:/apps/eliza-R6/sunos5/bin:. eeiatuc282 eeicjon 103> which sed sed: aliased to /client_local/exec/sed/bin/sed eeiatuc282 eeicjon 104> sed -V GNU sed version 3.02 Copyright (C) 1998 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, to the extent permitted by law. eeiatuc282 eeicjon 105> which gcc /home/atus07C/apps4/apssystem_v3.2/bin/gcc eeiatuc282 eeicjon 106> gcc -v /home/atus07C/apps4/apssystem_v3.2/lib/cse/c_compiler/bin/gcc -B/home/atus07C/apps4/apssystem_v3.2/lib/cse/c_compiler/lib/gcc-lib/sun4/ericsson/ -v Reading specs from /home/atus07C/apps4/apssystem_v3.2/lib/cse/c_compiler/lib/gcc-lib/sun4/ericsson/specs gcc version 2.9-gnupro-98r2 eeiatuc282 eeicjon 107> which make make:aliased to /client_local/exec/make/bin/make eeiatuc282 eeicjon 108> make -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.7 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to <[EMAIL PROTECTED]>. eeiatuc282 eeicjon 109> ## Thanks in advance for any help you can give me on this one. -- Ciaran Johnston Ericsson Systems Expertise Ltd., Athlone Co. Westmeath Eire email: [EMAIL PROTECTED] Phone: +353 902 31274 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] On the road
I will be on the road for the next two weeks. If something need to be done with ecpg please go ahead and make the changes. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
matthew green <[EMAIL PROTECTED]> writes: > digging into the regression.diffs, i can see that: > - reltime failed because it just had: > ! psql: Backend startup failed >The postmaster log file should have more info, but a first thought is >that you ran up against process or swap-space limitations. The parallel >check has fifty-odd processes going at its peak, which is more than the >default per-user process limit on many Unixen. > hmm, maxproc=80 on this system currently and i wasn't really doing anything > else. it has 256MB ram and 280MB swap (unused). exactly what am i looking > for in the postmaster.log file? it is 65kb long... Look for messages about "fork failed". They should give a kernel error message too. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
Tom Ivar Helbekkmo <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: > CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops); > + ERROR: cannot read block 3 of hash_i4_index: Bad address >> >> "Bad address"? That seems pretty bizarre. > This is obviously something that shows up on _some_ NetBSD platforms. If it's reproducible on more than one box then we should look into it. Am I right to guess that "Bad address" means a bogus pointer handed to a kernel call? If so, it'll probably take some digging with gdb to find out the cause. I'd be happy to do the digging if anyone can give me an account reachable via telnet or ssh on one of these machines. 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])
AW: [HACKERS] Re: TODO list
> > 1. Under "RELIABILITY/MISC", add: > > > > Write out a CRC with each data block, and verify it on reading. > TODO updated. I know we did number 2, but did we agree on #1 and is it > done? Has anybody done performance and reliability tests with CRC64 ? I think it must be a CPU eater. It looks a lot more complex than a CRC32. Since we need to guard a maximum of 32k bytes for pg pages I would - if at all - consider to use a 32bit adler instead of a CRC, since that is a lot cheaper to calculate. Andreas ---(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: AW: [HACKERS] Re: TODO list
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > Has anybody done performance and reliability tests with CRC64 ? > I think it must be a CPU eater. It looks a lot more complex than a CRC32. On my box (PA-RISC) the inner loop is about 14 cycles/byte, vs. about 7 cycles/byte for CRC32. On almost any machine, either one will be negligible in comparison to the cost of disk I/O. > Since we need to guard a maximum of 32k bytes for pg pages I would - > if at all - consider to use a 32bit adler instead of a CRC, since that > is a lot cheaper to calculate. You are several months too late to re-open that argument. It's done and it's not changing for 7.1. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ecpg long int problem on alpha + fix
Michael Meskes <[EMAIL PROTECTED]> writes: > I just committed some changes so that ecpg does acceptt "long long" > variables all the time, but repleces them with type "long" if > HAVE_LONG_LONG_INT_64 is not defined. This looks like a workable strategy for now. Ten years from now, when "long" means 64 bits everywhere and people are starting to use "long long" to mean 128 bits, we'll have to revisit it ;-) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: TODO list
> > > TODO updated. I know we did number 2, but did we agree on #1 and is it > > > done? > > > > #2 is indeed done. #1 is not done, and possibly not agreed to --- > > I think Vadim had doubts about its usefulness, though personally I'd > > like to see it. > > That was my recollection too. This was the discussion about testing the > disk hardware. #1 removed. What is recommended in the bible (Gray and Reuter), especially for larger disk block sizes that may not be written atomically, is to have a word at the end of the that must match a word at the beginning of the block. It gets changed each time you write the block. Ken Hirsch All your database are belong to us. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: TODO list
On Thu, Apr 05, 2001 at 04:25:42PM -0400, Ken Hirsch wrote: > > > > TODO updated. I know we did number 2, but did we agree on #1 and is > it > > > > done? > > > > > > #2 is indeed done. #1 is not done, and possibly not agreed to --- > > > I think Vadim had doubts about its usefulness, though personally I'd > > > like to see it. > > > > That was my recollection too. This was the discussion about testing the > > disk hardware. #1 removed. > > What is recommended in the bible (Gray and Reuter), especially for larger > disk block sizes that may not be written atomically, is to have a word at > the end of the that must match a word at the beginning of the block. It > gets changed each time you write the block. That only works if your blocks are atomic. Even SCSI disks reorder sector writes, and they are free to write the first and last sectors of an 8k-32k block, and not have written the intermediate blocks before the power goes out. On IDE disks it is of course far worse. (On many (most?) IDE drives, even when they have been told to report write completion only after data is physically on the platter, they will "forget" if they see activity that looks like benchmarking. Others just ignore the command, and in any case they all default to unsafe mode.) If the reason that a block CRC isn't on the TODO list is that Vadim objects, maybe we should hear some reasons why he objects? Maybe the objections could be dealt with, and everyone satisfied. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] Re: TODO list
> If the reason that a block CRC isn't on the TODO list is that Vadim > objects, maybe we should hear some reasons why he objects? Maybe > the objections could be dealt with, and everyone satisfied. Unordered disk writes are covered by backing up modified blocks in log. It allows not only catch such writes, as would CRC do, but *avoid* them. So, for what CRC could be used? To catch disk damages? Disk has its own CRC for this. Vadim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: TODO list
On Thu, Apr 05, 2001 at 02:27:48PM -0700, Mikheev, Vadim wrote: > > If the reason that a block CRC isn't on the TODO list is that Vadim > > objects, maybe we should hear some reasons why he objects? Maybe > > the objections could be dealt with, and everyone satisfied. > > Unordered disk writes are covered by backing up modified blocks > in log. It allows not only catch such writes, as would CRC do, > but *avoid* them. > > So, for what CRC could be used? To catch disk damages? > Disk has its own CRC for this. OK, this was already discussed, maybe while Vadim was absent. Should I re-post the previous text? Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
RE: [HACKERS] Re: TODO list
> > So, for what CRC could be used? To catch disk damages? > > Disk has its own CRC for this. > > OK, this was already discussed, maybe while Vadim was absent. > Should I re-post the previous text? Let's return to this discussion *after* 7.1 release. My main objection was (and is) - no time to deal with this issue for 7.1 Vadim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: TODO list
On Thu, Apr 05, 2001 at 02:47:41PM -0700, Mikheev, Vadim wrote: > > > So, for what CRC could be used? To catch disk damages? > > > Disk has its own CRC for this. > > > > OK, this was already discussed, maybe while Vadim was absent. > > Should I re-post the previous text? > > Let's return to this discussion *after* 7.1 release. > My main objection was (and is) - no time to deal with > this issue for 7.1. OK, everybody agreed on that before. This doesn't read like an objection to having it on the TODO list for some future release. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: TODO list
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes: >> If the reason that a block CRC isn't on the TODO list is that Vadim >> objects, maybe we should hear some reasons why he objects? Maybe >> the objections could be dealt with, and everyone satisfied. > Unordered disk writes are covered by backing up modified blocks > in log. It allows not only catch such writes, as would CRC do, > but *avoid* them. > So, for what CRC could be used? To catch disk damages? > Disk has its own CRC for this. Oh, I see. For anyone else who has trouble reading between the lines: Blocks that have recently been written, but failed to make it down to the disk platter intact, should be restorable from the WAL log. So we do not need a block-level CRC to guard against partial writes. A block-level CRC might be useful to guard against long-term data lossage, but Vadim thinks that the disk's own CRCs ought to be sufficient for that (and I can't say I disagree). So the only real benefit of a block-level CRC would be to guard against bits dropped in transit from the disk surface to someplace else, ie, during read or during a "cp -r" type copy of the database to another location. That's not a totally negligible risk, but is it worth the overhead of updating and checking block CRCs? Seems dubious at best. 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] Re: TODO list
> > So, for what CRC could be used? To catch disk damages? > > Disk has its own CRC for this. > > Oh, I see. For anyone else who has trouble reading between the lines: > > Blocks that have recently been written, but failed to make it down to > the disk platter intact, should be restorable from the WAL log. So we > do not need a block-level CRC to guard against partial writes. > > A block-level CRC might be useful to guard against long-term data > lossage, but Vadim thinks that the disk's own CRCs ought to be > sufficient for that (and I can't say I disagree). > > So the only real benefit of a block-level CRC would be to guard against > bits dropped in transit from the disk surface to someplace else, ie, > during read or during a "cp -r" type copy of the database to another > location. That's not a totally negligible risk, but is it worth the > overhead of updating and checking block CRCs? Seems dubious at best. Agreed. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: TODO list
On Thu, Apr 05, 2001 at 06:25:17PM -0400, Tom Lane wrote: > "Mikheev, Vadim" <[EMAIL PROTECTED]> writes: > >> If the reason that a block CRC isn't on the TODO list is that Vadim > >> objects, maybe we should hear some reasons why he objects? Maybe > >> the objections could be dealt with, and everyone satisfied. > > > Unordered disk writes are covered by backing up modified blocks > > in log. It allows not only catch such writes, as would CRC do, > > but *avoid* them. > > > So, for what CRC could be used? To catch disk damages? > > Disk has its own CRC for this. > > Blocks that have recently been written, but failed to make it down to > the disk platter intact, should be restorable from the WAL log. So we > do not need a block-level CRC to guard against partial writes. If a block is missing some sectors in the middle, how would you know to reconstruct it from the WAL, without a block CRC telling you that the block is corrupt? > A block-level CRC might be useful to guard against long-term data > lossage, but Vadim thinks that the disk's own CRCs ought to be > sufficient for that (and I can't say I disagree). The people who make the disks don't agree. They publish the error rate they guarantee, and they meet it, more or less. They publish a rate that is _just_ low enough to satisfy noncritical requirements (on the correct assumption that they can't satisfy critical requirements in any case) and high enough not to interfere with benchmarks. They assume that if you need better reliability you can and will provide it yourself, and rely on their CRC only as a performance optimization. At the raw sector level, they get (and correct) errors very frequently; when they are not getting "enough" errors, they pack the bits more densely until they do, and sell a higher-density drive. > So the only real benefit of a block-level CRC would be to guard against > bits dropped in transit from the disk surface to someplace else, ie, > during read or during a "cp -r" type copy of the database to another > location. That's not a totally negligible risk, but is it worth the > overhead of updating and checking block CRCs? Seems dubious at best. Vadim didn't want to re-open this discussion until after 7.1 is out the door, but that "dubious at best" demands an answer. See the archive posting: http://www.postgresql.org/mhonarc/pgsql-hackers/2001-01/msg00473.html ... Incidentally, is the page at http://www.postgresql.org/mhonarc/pgsql-hackers/2001-01/ the best place to find old messages? It's never worked right for me. Nathan Myers [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: TODO list
At 18:25 5/04/01 -0400, Tom Lane wrote: > >A block-level CRC might be useful to guard against long-term data >lossage, but Vadim thinks that the disk's own CRCs ought to be >sufficient for that (and I can't say I disagree). > >So the only real benefit of a block-level CRC would be to guard against >bits dropped in transit from the disk surface to someplace else What about guarding against file system problems, like blocks of one (non-PG) file erroneously writing to blocks of another (PG table) file? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] Re: TODO list
> > Blocks that have recently been written, but failed to make > > it down to the disk platter intact, should be restorable from > > the WAL log. So we do not need a block-level CRC to guard > > against partial writes. > > If a block is missing some sectors in the middle, how would you know > to reconstruct it from the WAL, without a block CRC telling you that > the block is corrupt? On recovery we unconditionally copy *entire* block content from the log for each block modified since last checkpoint. And we do not write new checkpoint record (ie do not advance recovery start point) untill we know that all data blocks are flushed on disk (including blocks modified before checkpointer started). Vadim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: TODO list
Philip Warner <[EMAIL PROTECTED]> writes: >> So the only real benefit of a block-level CRC would be to guard against >> bits dropped in transit from the disk surface to someplace else > What about guarding against file system problems, like blocks of one > (non-PG) file erroneously writing to blocks of another (PG table) file? Well, what about it? Can you offer numbers demonstrating that this risk is probable enough to justify the effort and runtime cost of a block CRC? If we're in the business of expending cycles to guard against nil-probability risks, let's checksum our executables every time we start up, to make sure they're not overwritten. Actually, we'd better re-checksum program text memory every few seconds, in case RAM dropped a bit since we looked last. And let's follow every memcpy by a memcmp to make sure that didn't drop a bit. Heck, let's keep a CRC on every palloc'd memory block. And so on and so forth. Sooner or later you've got to draw the line at diminishing returns, both for runtime costs and for the programming effort you spent on this stuff (instead of on finding/fixing bugs that might bite you with far greater frequency than anything a CRC might catch for you). To be perfectly clear: I have actually seen bug reports trace to problems that I think a block-level CRC might have detected (not corrected, of course, but at least the user might have realized he had flaky hardware a little sooner). So I do not say that the upside to a block CRC is nil. But I am unconvinced that it exceeds the downside, in development effort, runtime, false failure reports (is that CRC error really due to hardware trouble, or a software bug that failed to update the CRC? and how do you get around the CRC error to get at your data??) etc etc. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] RC3 ... anyone have anything left outstanding?
Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test?
Does anyone else have anything left outstanding that should hold me off
from doing an RC3 tomorrow?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RC3 ... anyone have anything left outstanding?
The Hermit Hacker <[EMAIL PROTECTED]> writes: > Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test? Still not there in CVS ... > Does anyone else have anything left outstanding that should hold me off > from doing an RC3 tomorrow? Other than a better answer for the horology test, I think we are good to go. The main thing that was still bothering me was Konstantin Solodovnikov's report of database corruption. I just committed a fix for the primary cause of that problem: turns out he was triggering a random transfer of control inside plpgsql. (Calling through a previously freed function pointer is uncool...) I'm guessing that the ensuing corruption of the database can be blamed on whatever bit of code managed to misexecute before the backend crashed completely. This is plausible because he reports that he only saw corruption in perhaps one out of every several hundred repetitions of the crash --- it makes sense that you'd need to mistransfer just so to result in writing junk XLOG entries or whatever was the direct cause of the data corruption. Vadim is still poking at the test case Konstantin sent, but I'll bet he won't be able to reproduce any corruption. The effects of jumping through an overwritten function pointer would be exceedingly system-specific. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RC3 ... anyone have anything left outstanding?
Okay, unless I hear different from anyone out there, I'm goin to roll RC3
when I get to work tomorrow, and announce it before I leave (to give it
some time to propogate to the mirrors) ...
On Thu, 5 Apr 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test?
>
> Still not there in CVS ...
>
> > Does anyone else have anything left outstanding that should hold me off
> > from doing an RC3 tomorrow?
>
> Other than a better answer for the horology test, I think we are good
> to go. The main thing that was still bothering me was Konstantin
> Solodovnikov's report of database corruption. I just committed a fix
> for the primary cause of that problem: turns out he was triggering a
> random transfer of control inside plpgsql. (Calling through a
> previously freed function pointer is uncool...) I'm guessing that the
> ensuing corruption of the database can be blamed on whatever bit of code
> managed to misexecute before the backend crashed completely. This is
> plausible because he reports that he only saw corruption in perhaps one
> out of every several hundred repetitions of the crash --- it makes sense
> that you'd need to mistransfer just so to result in writing junk XLOG
> entries or whatever was the direct cause of the data corruption.
>
> Vadim is still poking at the test case Konstantin sent, but I'll bet
> he won't be able to reproduce any corruption. The effects of jumping
> through an overwritten function pointer would be exceedingly
> system-specific.
>
> regards, tom lane
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: TODO list
At 22:52 5/04/01 -0400, Tom Lane wrote: > >> What about guarding against file system problems, like blocks of one >> (non-PG) file erroneously writing to blocks of another (PG table) file? > >Well, what about it? Can you offer numbers demonstrating that this risk >is probable enough to justify the effort and runtime cost of a block >CRC? Rhetorical crap aside, I've had more file system falures (including badly mapped file data) than I have had disk hardware failures. So, if you are considering 'bits dropped in transit', you should also be considering data corruption not related to the hardware. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] Foreign Key & Rule confusion WAS: Lost Trigger(s)?
Found the issue. Try out the attached SQL in a fresh database.
I had honestly expected the second delete to work properly as nothing
had to be removed that table.
The rule was added as a temporary measure to protect the data
currently in the table -- without the intent of otherwise impeding the
other informations use. I suppose I forgot that the table wouldn't be
looked at as the rule is checked quite early.
CREATE TABLE junk_parent (
col SERIAL PRIMARY KEY
);
INSERT INTO junk_parent DEFAULT VALUES;
INSERT INTO junk_parent DEFAULT VALUES;
INSERT INTO junk_parent DEFAULT VALUES;
CREATE TABLE junk (
col int4 NOT NULL REFERENCES junk_parent(col) ON UPDATE CASCADE ON
DELETE CASCADE
);
INSERT INTO junk VALUES ('1');
DELETE FROM junk_parent WHERE col = 1;
DELETE FROM junk_parent WHERE col = 2;
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:VCARD
VERSION:2.1
N:Taylor;Rod;B
FN:Taylor, Rod B
ORG:BarChord Entertainment Inc.;System Operation and Development
TITLE:Chief Technical Officer
ADR;WORK:;;;Toronto;Ontario;;Canada
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Toronto, Ontario=0D=0ACanada
X-WAB-GENDER:2
URL:
URL:http://www.barchord.com
BDAY:19790401
EMAIL;INTERNET:[EMAIL PROTECTED]
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
EMAIL;INTERNET:[EMAIL PROTECTED]
REV:20010405T232745Z
END:VCARD
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: Call for platforms
Bottom line: 7.1RC1 passes most of the regression tests on NetBSD/macppc. It's probably good enough for normal use since the differences are not extensive, but someone would need to look at the diff's for longer than the 10 seconds or so I've spent so far, and someone should actually set it up for real use to check that. I used the vanilla tarball from postgresql.org, not the NetBSD package system. Details: It's clearly less clean than the OS X build. Also my G4 desktop runs rings around both a Sun Ultra 1 and the 8500 I have NetBSD on for stuff like this build. I'm actually reevaluating how much I want to keep running real open source OS's vs the partly open MacOS X when both the OS and this application runs so much cleaner on the most recent (fastest) hardware. I like Apple stuff, but I never thought I would be this impressed with OS X this quickly. I guess I should shut up now or risk a flame war since the point is the PG port quality and not how good the target platform is. >% gmake check >gmake -C ../../../contrib/spi REFINT_VERBOSE=1 refint.so autoinc.so >gmake[1]: Entering directory `/usr/local/dist/postgresql-7.1RC1/contrib/spi' >gmake[1]: `refint.so' is up to date. >gmake[1]: `autoinc.so' is up to date. >gmake[1]: Leaving directory `/usr/local/dist/postgresql-7.1RC1/contrib/spi' >/bin/sh ./pg_regress --temp-install --top-builddir=../../.. >--schedule=./parallel_schedule --multibyte= >== removing existing temp installation== >== creating temporary installation== >== initializing database system == >== starting postmaster== >running on port 65432 with pid 21643 >== creating database "regression" == >CREATE DATABASE >== installing PL/pgSQL== >== running regression test queries== >parallel group (13 tests): text float4 varchar oid int2 char >boolean int4 int8 name float8 bit numeric > boolean ... ok > char ... ok > name ... ok > varchar ... ok > text ... ok > int2 ... ok > int4 ... ok > int8 ... ok > oid ... ok > float4 ... ok > float8 ... ok > bit ... ok > numeric ... ok >test strings ... ok >test numerology ... ok >parallel group (18 tests): path interval date time circle reltime >box lseg abstime inet point comments tinterval polygon timestamp >type_sanity oidjoins opr_sanity > point... ok > lseg ... ok > box ... ok > path ... ok > polygon ... ok > circle ... ok > date ... ok > time ... ok > timestamp... ok > interval ... ok > abstime ... ok > reltime ... ok > tinterval... ok > inet ... ok > comments ... ok > oidjoins ... ok > type_sanity ... ok > opr_sanity ... ok >test geometry ... FAILED >test horology ... FAILED >test create_function_1... ok >test create_type ... ok >test create_table ... ok >test create_function_2... ok >test copy ... ok >parallel group (7 tests): create_operator create_aggregate inherit >triggers constraints create_misc create_index > constraints ... ok > triggers ... ok > create_misc ... ok > create_aggregate ... ok > create_operator ... ok > create_index ... ok > inherit ... ok >test create_view ... ok >test sanity_check ... ok >test errors ... ok >test select ... ok >parallel group (16 tests): arrays select_having select_distinct >transactions random portals select_into union select_distinct_on >select_implicit case subselect aggregates btree_index join hash_index > select_into ... ok > select_distinct ... ok > select_distinct_on ... ok > select_implicit ... ok > select_having... ok > subselect... ok > union... ok > case ... ok > join ... ok > aggregates ... ok > transactions ... ok > random ... ok > portals ... ok > arrays ... ok > btree_index ... ok > hash_index ... ok >test misc ... ok >parallel group (5 tests): portals_p2 alter_table foreign_key >select_views rules > select_
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
> after running `unlimit' (tcsh) before `make check', the only failures i have > are the horology (expected) and the inherit sorted failures, on NetBSD/sparc64. I'll mark both NetBSD/sparc as supported, for both 32 and 64-bit builds. Thanks! - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Call for platforms
> Bottom line: 7.1RC1 passes most of the regression tests on > NetBSD/macppc. It's probably good enough for normal use since the > differences are not extensive, but someone would need to look at the > diff's for longer than the 10 seconds or so I've spent so far, and > someone should actually set it up for real use to check that. I'll mark it as supported; the horology diffs are not significant and geometry is known to be a bit different on some platforms. Including the not-tested-for-7.1 NetBSD/m68k, we are supported on 30 platforms for the upcoming release, with definite potential for a couple of more (QNX and Ultrix). *That* is some sort of milestone! :)) - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
"Henry B. Hotz" <[EMAIL PROTECTED]> writes: > Bottom line: 7.1RC1 passes most of the regression tests on > NetBSD/macppc. The only thing that surprised me here was all of the warnings from libreadline calls: >> tab-complete.c: In function `initialize_readline': >> tab-complete.c:103: warning: assignment from incompatible pointer type >> tab-complete.c: In function `psql_completion': >> tab-complete.c:292: warning: passing arg 2 of `completion_matches' >> from incompatible pointer type >> tab-complete.c:296: warning: passing arg 2 of `completion_matches' >> from incompatible pointer type What version of libreadline do you have installed, and how does it declare completion_matches()? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Foreign Key & Rule confusion WAS: Lost Trigger(s)?
"Rod Taylor" <[EMAIL PROTECTED]> writes: > Found the issue. Try out the attached SQL in a fresh database. And? AFAICT it behaves as expected, in either 7.0.2 or current ... 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])
[HACKERS] Re: RC3 ... anyone have anything left outstanding?
> Okay, unless I hear different from anyone out there, I'm goin to roll RC3 > when I get to work tomorrow, and announce it before I leave (to give it > some time to propogate to the mirrors) ... > > The Hermit Hacker <[EMAIL PROTECTED]> writes: > > > Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test? > > Still not there in CVS ... I've committed a fix to the horology regression test which keeps *some* kind of test for the "time with time zone" type with an implicit time zone. Not ideal, but we can work on it later. btw, I've applied the patch for the expected/ files to all variants of horology.out, so all platforms should pass that test now. I've also committed the up to date platform list, which has 30 distinct platforms supported!! Thanks to Henry Hotz for getting us to that magic number with NetBSD/ppc. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ... anyone have anything left outstanding?
Thomas Lockhart <[EMAIL PROTECTED]> writes: > btw, I've applied the patch for the expected/ files to all variants of > horology.out, so all platforms should pass that test now. FWIW, I confirm that horology-no-DST-before-1970 is good; it passes on HPUX. Can anyone confirm horology-solaris-1947? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
