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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
17 matches
Mail list logo
