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: [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
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
"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
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
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] 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
