| From: | Rui DeSousa <rui(dot)desousa(at)icloud(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | pavan95 <pavan(dot)postgresdba(at)gmail(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix |
| Date: | 2018-06-12 16:46:20 |
| Message-ID: | 957A97A0-73D7-4F53-B34A-E086AEC80596@icloud.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
> On Jun 12, 2018, at 12:16 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Tue, Jun 12, 2018 at 8:21 AM, Rui DeSousa <rui(dot)desousa(at)icloud(dot)com> wrote:
>> Note that DBCC was never a selling point and neither is fsck; the fact that those tools are needed is a problem.
>
> DBCC is a selling point. "Parallel consistency check" is a feature
> that is only available in SQL Server enterprise edition.
That’s not what I recall; it was clearly used against it in sales pitches. Do you really want to trust a database that requires you to DBCC checkdb periodically and fix corruption data pages or do you want to trust Oracle with data?
Would you use a filesystem today that required you to fsck after a crash?
Sure DBCC has useful features like tracing, etc. — it’s not just for corruption.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-06-12 16:51:39 | Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix |
| Previous Message | Peter Geoghegan | 2018-06-12 16:16:21 | Re: PostgreSQL 'Corruption & Fragmentation' detection and resolution/fix |