Re: [PoC PATCH] Parallel dump to /dev/null

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Christoph Berg <christoph(dot)berg(at)credativ(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andreas 'ads' Scherbaum <adsmail(at)wars-nicht(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PoC PATCH] Parallel dump to /dev/null
Date: 2018-03-22 01:33:07
Message-ID: 20180322013307.GC2490@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 21, 2018 at 09:07:41AM +0100, Michael Banck wrote:
> Am Dienstag, den 20.03.2018, 19:19 -0400 schrieb Stephen Frost:
>> Instead of trying to use pg_dump for this, we should provide a way to
>> actually check for corruption across everything (instead of just the
>> heap..), and have all detected corruption reported in one pass.
>
> Well, I agree that we should provide a more general tool as well.

A background worker is one piece of the puzzle, and while automatic scan
and checks would be nice, I don't think that is is mandatory as one
could as well have a script running as a cron job. My point is: you are
going to need a generic tool able to do the sanity checks and the
scanning, the way to invoke or run the tool is just more sugar on top of
the cake.

Note that there is still a patch pending for amcheck for add support for
heap checks, which is based on a bloom filter method. Impossible to say
if this is going to make it to upstream for v11. For the time being
Peter G has worked on a more advanced tool which is basically using the
patch submitted and maintains it here:
https://github.com/petergeoghegan/amcheck

The module has been renamed to amcheck_next to not conflict with what
upstream has since v10.

Hence, is there any objection to mark this patch as returned with
feedback? Corruption tools are definitely wanted, but not in this shape
per the feedback gathered on this thread.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-03-22 01:39:57 Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two
Previous Message Tom Lane 2018-03-22 01:27:11 Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs