| From: | Christoph Berg <christoph(dot)berg(at)credativ(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, 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-20 14:31:41 |
| Message-ID: | 20180320143141.GE32205@msg.credativ.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Re: Michael Paquier 2018-03-20 <20180320135720(dot)GE13368(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-03-20 14:36:15 | Re: XID-assigned idle transactions affect vacuum's job. |
| Previous Message | Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= | 2018-03-20 14:23:12 | Re: configure's checks for --enable-tap-tests are insufficient |