Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Undetected corruption of table files

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: ("Trevor Talbot" <quension(at)gmail(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>)
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Undetected corruption of table files
Date: 2007-08-28 14:33:27
Message-ID: 200708281436.l7SEajp6077914@smtp6.jaring.my (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
At 11:48 PM 8/27/2007, Trevor Talbot wrote:
>On 8/27/07, Jonah H. Harris <jonah(dot)harris(at)gmail(dot)com> wrote:
> > On 8/27/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > that and the lack of evidence that they'd actually gain anything
> >
> > I find it somewhat ironic that PostgreSQL strives to be fairly
> > non-corruptable, yet has no way to detect a corrupted page.  The only
> > reason for not having CRCs is because it will slow down performance...
> > which is exactly opposite of conventional PostgreSQL wisdom (no
> > performance trade-off for durability).
>
>But how does detecting a corrupted data page gain you any durability?
>All it means is that the platform underneath screwed up, and you've
>already *lost* durability.  What do you do then?

The benefit I see is you get to change the platform underneath 
earlier than later.

Whether that's worth it or not I don't know - real world stats/info 
would be good.

Even my home PATA drives tend to grumble about stuff first before 
they fail, so it might not be worthwhile doing the extra work.

Regards,
Link.




In response to

pgsql-hackers by date

Next:From: Kynn JonesDate: 2007-08-28 14:36:22
Subject: Re: One database vs. hundreds?
Previous:From: Tom LaneDate: 2007-08-28 14:28:24
Subject: Re: Testing the other tsearch dictionaries

pgsql-general by date

Next:From: Kynn JonesDate: 2007-08-28 14:36:22
Subject: Re: One database vs. hundreds?
Previous:From: Jeff AmielDate: 2007-08-28 14:30:01
Subject: Re: Tables dissapearing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group