Bruce Guenter wrote:
CRCs are designed to catch N-bit errors (ie N bits in a row with their
values flipped). N is (IIRC) the number of bits in the CRC minus one.
So, a 32-bit CRC can catch all 31-bit errors. That's the only guarantee
a CRC gives. Everything else has a 1 in 2^32-1 chance
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
Yes, but there would need to be a way to verify the last page or
record from txlog when running on crap hardware.
How exactly *do* we determine where the end of the valid log data is,
anyway?
regards, tom lane
Tom Lane wrote:
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
Yes, but there would need to be a way to verify the last page or
record from txlog when running on crap hardware.
How exactly *do* we determine where the end of the valid log data is,
anyway?
Couldn't you use a CRC ?
On Wed, Dec 06, 2000 at 11:15:26AM -0500, Tom Lane wrote:
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
Yes, but there would need to be a way to verify the last page or
record from txlog when running on crap hardware.
How exactly *do* we determine where the end of the valid log data is,
Bruce Guenter wrote:
- Assume that a CRC is a guarantee. A CRC would be a good addition to
help ensure the data wasn't broken by flakey drive firmware, but
doesn't guarantee consistency.
Even a CRC per transaction (it could be a nice END record) ?
Bye!
--
Daniele
NO, I just tested how solid PgSQL is, I run a program busy inserting record into
PG table, when I
suddenly pulled out power from my machine and restarted PG, I can not insert any
record into database
table, all backends are dead without any respone (not core dump), note that I am
