From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Michael Banck <michael(dot)banck(at)credativ(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: More issues with pg_verify_checksums and checksum verification in base backups |
Date: | 2019-08-05 07:30:52 |
Message-ID: | 20190805073051.GH1740@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 03, 2019 at 06:47:48PM +0200, Michael Banck wrote:
> first off, a bit of a meta-question: Did the whitelist approach die
> completely, or are we going to tackle it again for v13 or later?
At this stage, it is burried. Amen.
> This is something I still have in the test suite of my pg_checksums
> fork, cause I never reverted that one from isRelFile() back to
> skipfile() (so it doesn't fail on the above cause `123.' is not
> considered a relation file worth checksumming).
We could actually fix this one. It is confusing to have pg_checksums
generate a report about a segment number which is actually incorrect.
> Independently of the whitelist/blacklist question, I believe
> pg_checksums should not error out as soon as it encounters a weird looking
> file, but either (i) still checksum it or (ii) skip it? Or is that to be
> considered a pilot error and it's fine for pg_checksums to fold?
That's actually the distinctions between the black and white lists
which would have handled that.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-08-05 07:45:59 | Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions? |
Previous Message | tushar | 2019-08-05 07:29:29 | SSL Connection still showing TLSv1.3 even it is disabled in ssl_ciphers |