From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | "Maxim Boguk *EXTERN*" <maxim(dot)boguk(at)gmail(dot)com>, Yuri Budilov <yuri(dot)budilov(at)hotmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: moving to PostgreSQL from MS-SQL and from Oracle, looking for feature comparison information |
Date: | 2015-05-10 13:34:33 |
Message-ID: | CAOR=d=3sf8g9tsxphkWYDKcds7nu78HLfS=0Of3LiR_KV5vWAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, May 9, 2015 at 11:20 PM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> Maxim Boguk wrote:
>> It's depend where a corruption happen, if pages become corrupted due to some
>> problems with physical storage (filesystem) in that case a replica data should be ok.
>
> I would not count on that.
> I have had a case where a table file got corrupted due to hardware problems.
> Pages that contained data were suddenly zeroed.
> PostgreSQL recognizes such a block as empty, so the user got no error, but
> data were suddenly missing. What does a user do in such a case? He/she grumbles
> and enters the data again. This insert will be replicated to the standby (which was
> fine up to then) and will cause data corruption there (duplicate primary keys).
You had zero corrupted pages turned on. PostgreSQL by default does NOT
DO THIS. That setting is for recovering a corrupted database not for
everyday use!
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2015-05-10 13:50:32 | Re: moving to PostgreSQL from MS-SQL and from Oracle, looking for feature comparison information |
Previous Message | Stephen Frost | 2015-05-10 11:24:46 | Re: moving to PostgreSQL from MS-SQL and from Oracle, looking for feature comparison information |