On Sun, May 10, 2015 at 7:50 AM, Albe Laurenz <laurenz.a...@wien.gv.at> wrote: > Scott Marlowe wrote: >> On Sat, May 9, 2015 at 11:20 PM, Albe Laurenz <laurenz.a...@wien.gv.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! > > No, I didn't. > > It was not PostgreSQL that zeroed the page, but the hardware or operating > system. > The problem was a flaky fibre channel cable that intermittently was connected > and disconnected. > That corrupted the file system, and I guess it must have been file system > recovery > that zeroed the pages. I'm not 100% certain, at any rate the symptoms were > silently missing data.
Ahh OK. So broken hardware. I've seen some RAID controlelrs do that. Sorry but your post didn't make it clear where the zeroing came from. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
