From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Bossart, Nathan <bossartn@amazon.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: 蔡梦娟(玊于) <mengjuan.cmj@alibaba-inc.com>
Cc: Jakub Wartak <Jakub.Wartak@tomtom.com>
Subject: Re: prevent immature WAL streaming
Date: Wed, 1 Sep 2021 15:01:43 +0900
Message-ID: <8acc33c8-fb75-fda4-8909-50d21f9e8725@oss.nttdata.com> (raw)
In-Reply-To: <20210901031524.mdo6aayalmd5jxly@alap3.anarazel.de>
References: <20210831042949.52eqp5xwbxgrfank@alap3.anarazel.de>
<202108311356.sl33wcpcz5x6@alvherre.pgsql>
<20210831155333.2vv2zdf7v4nhh2m2@alap3.anarazel.de>
<bb15b918-6dad-b01d-23b9-17b5dfa7e6a2@oss.nttdata.com>
<20210901031524.mdo6aayalmd5jxly@alap3.anarazel.de>
On 2021/09/01 12:15, Andres Freund wrote:
> Hi,
>
> On 2021-09-01 11:34:34 +0900, Fujii Masao wrote:
>> On 2021/09/01 0:53, Andres Freund wrote:
>>> Of course, we need to be careful to not weaken WAL validity checking too
>>> much. How about the following:
>>>
>>> If we're "aborting" a continued record, we set XLP_FIRST_IS_ABORTED_PARTIAL on
>>> the page at which we do so (i.e. the page after the valid end of the WAL).
>>
>> When do you expect that XLP_FIRST_IS_ABORTED_PARTIAL is set? It's set
>> when recovery finds a a partially-flushed segment-spanning record?
>> But maybe we cannot do that (i.e., cannot overwrite the page) because
>> the page that the flag is set in might have already been archived. No?
>
> I was imagining that XLP_FIRST_IS_ABORTED_PARTIAL would be set in the "tail
> end" of a partial record. I.e. if there's a partial record starting in the
> successfully archived segment A, but the end of the record, in B, has not been
> written to disk before a crash, we'd set XLP_FIRST_IS_ABORTED_PARTIAL at the
> end of the valid data in B. Which could not have been archived yet, or we'd
> not have a partial record. So we should never need to set the flag on an
> already archived page.
Thanks for clarifying that! Unless I misunderstand that, when recovery ends
at a partially-flushed segment-spanning record, it sets
XLP_FIRST_IS_ABORTED_PARTIAL in the next segment before starting writing
new WAL data there. Therefore XLP_FIRST_IS_CONTRECORD or
XLP_FIRST_IS_ABORTED_PARTIAL must be set in the next segment following
a partially-flushed segment-spanning record. If none of them is set,
the validation code in recovery should report an error.
Yes, this design looks good to me.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: masao.fujii@oss.nttdata.com, andres@anarazel.de, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org, bossartn@amazon.com, horikyota.ntt@gmail.com, mengjuan.cmj@alibaba-inc.com, Jakub.Wartak@tomtom.com
Subject: Re: prevent immature WAL streaming
In-Reply-To: <8acc33c8-fb75-fda4-8909-50d21f9e8725@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox