Re: Corruption during WAL replay

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