On Wed, Jul 29, 2026 at 4:09 PM ahmed <gouda0x@gmail.com> wrote:
>
> Hi Jakub, The use case that this feature addresses is interesting, but the proposed implementation feels a bit ad-hoc
tous:
>
> 1. `COPY ... TO ...` implies moving data from one place to another. Having a `BLACKHOLE` destination whose purpose is
tocheck for data corruption seems counter-intuitive.
> 2. The argument to `pg_dump --format=...` specifies an archive format. A `blackhole` archive format and the
`archBlackhole`entry in the `ArchiveFormat` enum in the `pg_dump` code also seem ad-hoc and counter- intuitive, because
nothingis actually being archived.
> For those reasons, I don't think `COPY` or `pg_dump` is the right place to support this use case. Perhaps this needs
anew command, but that might overcomplicate things. In that case, I would prefer to leave things as they are.
Hi Ahmed & Milosz,
thanks for reminding me of this old thread :)
I partially agree. Let me explain, this was based on minimal changes approach
to have it in and re-use parallel scheduling for this SQL syntax in pg_dump
(the primary idea is to have one simple one-liner command that people could
use to logically check their databases somewhat similiar to pg_amcheck, but
using more-rigorious "COPY" than amcheck functions do itself; to this day
people are using pg_dump > /dev/null for this but it really writes and sadly
cannot use --jobs).
Perhaps we should have some other command or even amcheck function to do the
same, but that would re-implementation of everything that actually COPY does,
so maybe instead it would be good idea to have COPY .. TO BLACKHOLE (or COPY
VERIFY %tablename%?), but support launching many jobs using pg_amcheck --jobs
rather than having pg_dump --jobs (and as You mention this is not archiving),
as it would be more suited for logical database verification. I'm pretty open
for speciifc naming proposals if anyone has those, before writing new version
of the patch.
-J.
