Subject: Re: Crash by targetted recovery
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
 pgsql-hackers@lists.postgresql.org
References: <20200227.124830.2197604521555566121.horikyota.ntt@gmail.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
Message-ID: <899463ee-549c-3f30-5752-ae1988ddc066@oss.nttdata.com>
Date: Thu, 27 Feb 2020 14:40:55 +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: <20200227.124830.2197604521555566121.horikyota.ntt@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2020/02/27 12:48, Kyotaro Horiguchi wrote:
> Hello.
> 
> We found that targetted promotion can cause an assertion failure.  The
> attached TAP test causes that.
> 
>> TRAP: FailedAssertion("StandbyMode", File: "xlog.c", Line: 12078)
> 
> After recovery target is reached, StartupXLOG turns off standby mode
> then refetches the last record. If the last record starts from the
> previous WAL segment, the assertion failure is triggered.

Good catch!

> The wrong point is that StartupXLOG does random access fetching while
> WaitForWALToBecomeAvailable is thinking it is still in streaming.  I
> think if it is called with random access mode,
> WaitForWALToBecomeAvailable should move to XLOG_FROM_ARCHIVE even
> though it is thinking that it is still reading from stream.

I failed to understand why random access while reading from
stream is bad idea. Could you elaborate why?

Isn't it sufficient to set currentSource to 0 when disabling
StandbyMode?

Regards,

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