| From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Database corruption: finding the bad block |
| Date: | 2007-07-12 14:31:23 |
| Message-ID: | 1184250683.24101.191.camel@coppola.muc.ecircle.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 2007-07-12 at 16:18, Simon Riggs wrote:
> The corruption could only migrate if the WAL records themselves caused
> the damage, which is much less likely than corruption of the data blocks
> at hardware level. ISTM that both Slony and Log shipping replication
> protect fairly well against block corruption on the standby, but only
> log shipping allows you to recover the precise block, as you describe.
Well, I could only speak of what I experienced, and that is that in the
total of 2 former file system level corruptions the replica was
corrupted too. This time it was not...
Because of that I had the impression Slony will be more immune to such
glitches, as it is not shuffling raw file data around... I mean you
still can have data corruption replicated, but the replica will be
functional. Our WAL standby did not start up at all when we had that
former file corruption issue...
Cheers,
Csaba.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-07-12 14:40:46 | Re: [GENERAL] Count(*) throws error |
| Previous Message | Simon Riggs | 2007-07-12 14:18:22 | Re: Database corruption: finding the bad block |