From: | Michael Banck <michael(dot)banck(at)credativ(dot)de> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Verify Checksums during Basebackups |
Date: | 2018-03-05 08:41:26 |
Message-ID: | 20180305084126.GG13784@nighthawk.caipicrew.dd-dns.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Sun, Mar 04, 2018 at 06:19:00PM +0100, Magnus Hagander wrote:
> So sure, if we go with WARNING + exit with an errorcode, that is perhaps
> the best combination of the two.
I had a look at how to go about this, but it appears to be a bit
complicated; the first problem is that sendFile() and sendDir() don't
have status return codes that could be set on checksum verifcation
failure. So I added a global variable and threw an ereport(ERROR) at the
end of perform_base_backup(), but then I realized that `pg_basebackup'
the client program purges the datadir it created if it gets an error:
|pg_basebackup: final receive failed: ERROR: Checksum mismatch during
|basebackup
|
|pg_basebackup: removing data directory "data2"
So I guess this would have to be sent back via the replication protocol,
but I don't see an off-hand way to do this easily?
Another option would be to see whether it is possible to verify the
checksum on the client side, but then only pg_basebackup (and no other
possible external tools using BASE_BACKUP) would profit.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael(dot)banck(at)credativ(dot)de
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
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2018-03-05 08:46:44 | Re: PATCH: psql tab completion for SELECT |
Previous Message | Amit Langote | 2018-03-05 08:38:17 | Re: [HACKERS] path toward faster partition pruning |