Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Sep 16, 2019 at 9:30 AM Robert Haas <robertmh...@gmail.com> wrote: > > > Isn't some operations where at the end we directly call heap_sync > > > without writing WAL will have a similar problem as well? > > > > Maybe. Can you give an example? > > Looking through the code, I found two cases where we do this. One is > a bulk insert operation with wal_level = minimal, and the other is > CLUSTER or VACUUM FULL with wal_level = minimal. In both of these > cases we are generating new blocks whose LSNs will be 0/0. So, I think > we need a rule that if the server is asked to back up all blocks in a > file with LSNs > some threshold LSN, it must also include any blocks > whose LSN is 0/0. Those blocks are either uninitialized or are > populated without WAL logging, so they always need to be copied.
I'm not sure I see a way around it but this seems pretty unfortunate- every single incremental backup will have all of those included even though the full backup likely also does (I say likely since someone could do a full backup, set the WAL to minimal, load a bunch of data, and then restart back to a WAL level where we can do a new backup, and then do an incremental, so we don't *know* that the full includes those blocks unless we also track a block-level checksum or similar). Then again, doing these kinds of server bounces to change the WAL level around is, hopefully, relatively rare.. > Outside of unlogged and temporary tables, I don't know of any case > where make a critical modification to an already-existing block > without bumping the LSN. I hope there is no such case. I believe we all do. :) Thanks, Stephen
signature.asc
Description: PGP signature
