On Wed, Mar 16, 2022 at 1:14 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > storage.c: > + * Make sure that a concurrent checkpoint can't complete while > truncation > + * is in progress. > + * > + * The truncation operation might drop buffers that the checkpoint > + * otherwise would have flushed. If it does, then it's essential that > + * the files actually get truncated on disk before the checkpoint > record > + * is written. Otherwise, if reply begins from that checkpoint, the > + * to-be-truncated buffers might still exist on disk but have older > + * contents than expected, which can cause replay to fail. It's OK for > + * the buffers to not exist on disk at all, but not for them to have > the > + * wrong contents. > > FWIW, this seems like slightly confusing between buffer and its > content. I can read it correctly so I don't mind if it is natural > enough.
Hmm. I think the last two instances of "buffers" in this comment should actually say "blocks". > I'll try that, if you are already working on it, please inform me. (It > may more than likely be too late..) If you want to take a crack at that, I'd be delighted. -- Robert Haas EDB: http://www.enterprisedb.com
