Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix

From: Rui DeSousa <rui(dot)desousa(at)icloud(dot)com>
To: Pavan Teja <pavan(dot)postgresdba(at)gmail(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix
Date: 2018-06-11 18:16:29
Message-ID: B7E2FA3A-5D81-4EBD-977E-1958520298AE@icloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


> On Jun 11, 2018, at 1:57 PM, Pavan Teja <pavan(dot)postgresdba(at)gmail(dot)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.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Pavan Teja 2018-06-11 18:18:27 Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix
Previous Message Pavan Teja 2018-06-11 17:57:18 Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix