Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix - Mailing list pgsql-admin

From Pavan Teja
Subject Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix
Date
Msg-id CACh9nsYOacwJ6D_sVenarjpVNNXgDdhSP-bFpdXVmoms5fkLOw@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL 'Corruption & Fragmentation' detection andresolution/fix  (Rui DeSousa <rui.desousa@icloud.com>)
Responses Re: PostgreSQL 'Corruption & Fragmentation' detection andresolution/fix
List pgsql-admin
Hi Rui,

Thank you for the clarification. 

On Mon, Jun 11, 2018, 11:46 PM Rui DeSousa <rui.desousa@icloud.com> wrote:

> On Jun 11, 2018, at 1:57 PM, Pavan Teja <pavan.postgresdba@gmail.com> wrote:
>
> So finally there's no script to determine corruption well in advance?? Correct??

It is your responsibility to make sure that the system is solid and all worst cases are covered along with striving for the five 9’s.  You need to building a system that you can trust which includes making sure you disk subsystem is really and I mean really reliable.  RAID is the most falsely trusted system around; so you really need to know the subsystems in your system especially when subsystems that break fsync().

Bit rot is real and if you system doesn’t handle it then that will lead to data corruption.  Postgres will only be able to tell you that it occurred if you have data_checksums feature enabled.  Your subsystem should handle it and actively be checking for it; however, most RAID systems don’t or fail to do a good job at it.

Like I stated already; If I couldn’t entrust the data integrity of Postgres I would not be using it and would be running Oracle instead.

pgsql-admin by date:

Previous
From: Rui DeSousa
Date:
Subject: Re: PostgreSQL 'Corruption & Fragmentation' detection andresolution/fix
Next
From: Rui DeSousa
Date:
Subject: Re: pg_stat_activity