Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1iSDX6-0006tj-09
	for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Nov 2019 05:07:04 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1iSDX4-0001Wp-M6
	for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Nov 2019 05:07:02 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <a.lepikhov@postgrespro.ru>)
	id 1iSDX3-0001RG-OY
	for pgsql-bugs@lists.postgresql.org; Wed, 06 Nov 2019 05:07:02 +0000
Received: from cyclops.postgrespro.ru ([93.174.131.138]
 helo=mail.postgrespro.ru)
	by makus.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <a.lepikhov@postgrespro.ru>)
	id 1iSDX0-0001u9-FU
	for pgsql-bugs@lists.postgresql.org; Wed, 06 Nov 2019 05:07:00 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.postgrespro.ru (Postfix) with ESMTP id 10EAE21C3FA9;
	Wed,  6 Nov 2019 08:06:56 +0300 (MSK)
X-Virus-Scanned: Debian amavisd-new at postgrespro.ru
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[]
	autolearn=unavailable
Received: from [192.168.0.108] (pool-77-222-104-35.is74.ru [77.222.104.35])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mail.postgrespro.ru (Postfix) with ESMTPSA id C0DED21C3F9C;
	Wed,  6 Nov 2019 08:06:55 +0300 (MSK)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru;
	s=mail; t=1573016815;
	bh=6qNeaz9AEOqSyFMrf5obpZFOI6dedrwZt4argDR5DhM=;
	h=Subject:To:Cc:References:From:Date:In-Reply-To;
	b=gbrpyGaC1jMi1rFetV0kTFxsibwa1P2Bp5snTOF0sen12TKwLUC3aC0c9DP0BzCb/
	 gmt2OjLEn08/c9NlXui6irO6DPC3pX2Ly3bRabVFkVSCDVfTz9y0LpakvSXkxJ5PDx
	 BCXkoyEHe8gmYEA9ED9vbgiGmU0z0yEOSF5DTin0=
Subject: Re: The XLogFindNextRecord() routine find incorrect record start
 point after a long continuation record
To: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
References: <99303554-5dd5-06e6-f943-b3005ccd6edd@postgrespro.ru>
 <20191106044120.GF1604@paquier.xyz>
From: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
Message-ID: <c57afeaf-4cf5-84a9-d19b-738f3f801e78@postgrespro.ru>
Date: Wed, 6 Nov 2019 10:06:55 +0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191106044120.GF1604@paquier.xyz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Precedence: bulk



On 06/11/2019 09:41, Michael Paquier wrote:
> On Wed, Nov 06, 2019 at 07:40:48AM +0500, Andrey Lepikhov wrote:
>> I found this in our multimaster project on PostgreSQL 11.5. It is difficult
>> to reproduce this error, but I will try to do it if necessary.
>>
>> The rest of a continuation WAL-record can exactly match the block size. In
>> this case, we need to switch targetPagePtr to the next block before
>> calculating the starting point of the next WAL-record.
>> See the patch in attachment for the bug fix.
> 
> What's the error you actually saw after reading the record in
> xlogreader.c?  If you have past WAL archives, perhaps you are able to
> reproduce the problem with a given WAL segment and pg_waldump?

I saw the message:
pg_waldump: xlogreader.c:264: XLogReadRecord: <Text in russian> 
"((RecPtr) % 8192 >= (((uintptr_t) ((sizeof(XLogPageHeaderData))) + ((8) 
- 1)) & ~((uintptr_t) ((8) - 1))))" <Text in russian>

Yes, I reproduced error with pg_waldump too. The patch in previous 
letter fixed this problem.

some details:
I have the record:
rmgr: Transaction len (rec/tot): 86/ 86, tx: 0, lsn: 0/11FFFF98, prev 
0/11FFFDA8, desc: COMMIT_PREPARED

The next record occupied the rest of segment No.11 and 8151 bytes of the 
first block of the segment No.12, i.e. its size is 8167 bytes.

Problematic record (I got it by pg_waldump after applying the patch) is:
rmgr: Heap len (rec/tot): 71/ 8167, tx: 1249835485258, lsn: 0/11FFFFF0, 
prev 0/11FFFF98, desc: LOCK off 8: xid 1249835485258: flags 0 LOCK_ONLY 
EXCL_LOCK KEYS_UPDATED , blkref #0: rel 1663/13121/16474 blk 10880 FPW

-- 
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company