On Thu, Apr 2, 2020 at 1:23 PM Andres Freund <and...@anarazel.de> wrote: > I suspect its possible to control the timing by preventing the > checkpoint at the end of recovery from completing within a relevant > timeframe. I think configuring a large checkpoint_timeout and using a > non-fast base backup ought to do the trick. The state can be advanced by > separately triggering an immediate checkpoint? Or by changing the > checkpoint_timeout?
That might make the window fairly wide on normal systems, but I'm not sure about Raspberry Pi BF members or things running CLOBBER_CACHE_ALWAYS/RECURSIVELY. I guess I could try it. > I think it might be worth looking, in a later release, at something like > blake3 for a fast cryptographic checksum. By allowing for instruction > parallelism (by independently checksuming different blocks in data, and > only advancing the "shared" checksum separately) it achieves > considerably higher throughput rates. > > I suspect we should also look at a better non-crypto hash. xxhash or > whatever. Not just for these checksums, but also for in-memory. I have no problem with that. I don't feel that I am well-placed to recommend for or against specific algorithms. Speed is easy to measure, but there's also code stability, the license under which something is released, the quality of the hashes it produces, and the extent to which it is cryptographically secure. I'm not an expert in any of that stuff, but if we get consensus on something it should be easy enough to plug it into this framework. Even changing the default would be no big deal. > FWIW, the only check I'd really like to see in this release is the > crosscheck with the files length and the actually read data (to be able > to disagnose FS issues). Not sure I understand this comment. Isn't that a subset of what the patch already does? Are you asking for something to be changed? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
