Re: [PoC PATCH] Parallel dump to /dev/null - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: [PoC PATCH] Parallel dump to /dev/null
Date
Msg-id 20180320143141.GE32205@msg.credativ.de
Whole thread Raw
In response to Re: [PoC PATCH] Parallel dump to /dev/null  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [PoC PATCH] Parallel dump to /dev/null  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Re: Michael Paquier 2018-03-20 <20180320135720.GE13368@paquier.xyz>
> Now, why are people using pg_dump > /dev/null?  Mainly the lack of
> better tools, which would be actually able to detect pages in corrupted
> pages in one run, and not only heap pages.  I honestly think that
> amcheck is something that we sould more focus on and has more potential
> on the matter, and that we are just complicating pg_dump to do something
> it is not designed for, and would do it badly anyway.

Still, people are using it for that purpose now, and speeding it up
would just be a non-intrusive patch.

Also, if pg_dump is a backup tool, why does that mean it must not be
used for anything else?

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE


pgsql-hackers by date:

Previous
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: Re: configure's checks for --enable-tap-tests are insufficient
Next
From: Tom Lane
Date:
Subject: Re: XID-assigned idle transactions affect vacuum's job.