Feedback-ID: ia2694551:Fastmail
Date: Fri, 23 Dec 2022 17:35:09 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Karina Litskevich <litskevichkarina@gmail.com>
Cc: =?utf-8?B?546L5rW35rSL?= <wanghaiyang.001@bytedance.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: [PATCH] BUG FIX: inconsistent page found in BRIN_REGULAR_PAGE
Message-ID: <20221223163509.rwxpzy6xfemppkxd@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a5559c95-52c3-5eea-cd63-9b4f1c70ff96@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20221223163509.rwxpzy6xfemppkxd%40alvherre.pgsql>
Precedence: bulk

Hello,

On 2022-Dec-23, Karina Litskevich wrote:

> Is there any special reason to read WAL records until the last inserted
> record?

Hmm, no, there's no good reason to do it that way.

> It seems that in some rare situations on slower machines this test can fail.
> If any background process inserts a WAL record before lsn('insert')
> and this record isn't flushed before
> pg_get_wal_records_info('$start_lsn', '$end_lsn'),
> pg_get_wal_records_info('$start_lsn', '$end_lsn') ends with ERROR
> "cannot accept future end LSN" as it works only if record with end LSN
> is inserted.

Hmm.  I've never seen that, but it sounds plausible.

> I attached two patches with two ways of fixing this minor issue.

> -my $end_lsn = $whiskey->lsn('insert');
> +my $end_lsn = $whiskey->lsn('flush');

Thank you, I used this one.

Regards

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/