On Mon, Apr 25, 2022 at 10:24:52AM -0500, David Christensen wrote: > On Mon, Apr 25, 2022 at 6:03 AM Bharath Rupireddy > <bharath.rupireddyforpostg...@gmail.com> wrote: >> Thanks for working on this. I'm just thinking if we can use these FPIs >> to repair the corrupted pages? I would like to understand more >> detailed usages of the FPIs other than inspecting with pageinspect. > > My main use case was for being able to look at potential corruption, > either in the WAL stream, on heap, or in tools associated with the WAL > stream. I suppose you could use the page images to replace corrupted > on-disk pages (and in fact I think I've heard of a tool or two that > try to do that), though don't know that I consider this the primary > purpose (and having toast tables and the list, as well as clog would > make it potentially hard to just drop-in a page version without > issues). Might help in extreme situations though.
You could do a bunch of things with those images, even make things worse if you are not careful enough. >> 10) Along with pg_pwrite(), can we also fsync the files (of course >> users can choose it optionally) so that the writes will be durable for >> the OS crashes? > > Can add; you thinking a separate flag to disable this with default true? We expect data generated by tools like pg_dump, pg_receivewal (depending on the use --synchronous) or pg_basebackup to be consistent when we exit from the call. FWIW, flushing this data does not seem like a strong requirement for something aimed at being used page-level chirurgy or lookups, because the WAL segments should still be around even if the host holding the archives is unplugged. -- Michael
signature.asc
Description: PGP signature
