On Wed, Mar 16, 2022 at 1:14 AM Kyotaro Horiguchi
<horikyota.ntt@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
