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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kynn Jones | 2007-08-28 14:36:22 | Re: One database vs. hundreds? |
Previous Message | Jeff Amiel | 2007-08-28 14:30:01 | Re: Tables dissapearing |
From | Date | Subject | |
---|---|---|---|
Next Message | Kynn Jones | 2007-08-28 14:36:22 | Re: One database vs. hundreds? |
Previous Message | Tom Lane | 2007-08-28 14:28:24 | Re: Testing the other tsearch dictionaries |