Subject: Re: Crash by targetted recovery
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
References: <0db8f83f-5b66-75e9-6d99-93f19fc33165@oss.nttdata.com>
 <20200306.102946.81443433484362211.horikyota.ntt@gmail.com>
 <00dac90c-c37d-0a99-6d4d-97acb48a06bf@oss.nttdata.com>
 <20200309.134927.754909343807949809.horikyota.ntt@gmail.com>
 <203fa5df-f98f-35ac-fea9-2aa2ffcdd31a@oss.nttdata.com>
Message-ID: <0e356860-2c03-bfe6-5256-40ac8f0d6333@oss.nttdata.com>
Date: Tue, 10 Mar 2020 10:50:52 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <203fa5df-f98f-35ac-fea9-2aa2ffcdd31a@oss.nttdata.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2020/03/09 15:46, Fujii Masao wrote:
> 
> 
> On 2020/03/09 13:49, Kyotaro Horiguchi wrote:
>> At Sat, 7 Mar 2020 01:46:16 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>>>> (It seems retroverting to the first patch when I started this...)
>>>> The second place covers wider cases so I reverted the first place.
>>>
>>> Thanks for updating the patch that way.
>>> Not sure which patch you're mentioning, though.
>>
>> That meant 0003.
>>
>>> Regarding 0003 patch, I added a bit more detail comments into
>>> the patch so that we can understand the code more easily.
>>> Updated version of 0003 patch attached. Barring any objection,
>>> at first, I plan to commit this patch.
>>
>> Looks good to me. Thanks for writing the detailed comments.
> 
> Thanks for the review! Pushed.
> 
> I will review other two patches later.

Pushed the v5-0001-Tidy-up-XLogSource-usage.patch!

Regarding the remaining patch adding the regression test,

+$result =
+  $node_standby->safe_psql('postgres', "SELECT pg_last_wal_replay_lsn()");
+my ($seg, $off) = split('/', $result);
+my $target = sprintf("$seg/%08X", (hex($off) / $segsize + 1) * $segsize);

What happens if "off" part gets the upper limit and "seg" part needs
to be incremented? What happens if pg_last_wal_replay_lsn() advances
very much (e.g., because of autovacuum) beyond the segment boundary
until the standby restarts? Of course, these situations very rarely happen,
but I'd like to avoid adding such not stable test if possible.

Regards,

-- 
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters