Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q44zp-0002j7-3E for pgsql-admin@arkaria.postgresql.org; Tue, 30 May 2023 19:27:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q44zn-0006xh-L7 for pgsql-admin@arkaria.postgresql.org; Tue, 30 May 2023 19:27:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q44zn-0006xX-AP for pgsql-admin@lists.postgresql.org; Tue, 30 May 2023 19:27:03 +0000 Received: from mout-u-107.mailbox.org ([80.241.59.207]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q44zf-0037bI-8G for pgsql-admin@lists.postgresql.org; Tue, 30 May 2023 19:27:02 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4QW2T83yxKz9sSM; Tue, 30 May 2023 21:26:52 +0200 (CEST) Date: Tue, 30 May 2023 21:26:51 +0200 (CEST) From: Erik Wienhold To: Victor Sudakov , pgsql-admin@lists.postgresql.org Message-ID: <34465465.518828.1685474811496@office.mailbox.org> In-Reply-To: References: Subject: Re: xlog min recovery request 7C5C/96D5C550 is past current point MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 28/05/2023 13:45 CEST Victor Sudakov wrote: > > Dear Colleagues, > > After starting a Postgres 13.11 cluster from a pg_basebackup'ed > directory, it started its recovery with lots of these messages in the log: > > 2024-05-26 03:30:26.526 MST [394116] WARNING: xlog min recovery request 7C5B/8AC06EA0 is past current point 7C5B/839449E8 > 2023-05-26 03:30:26.526 MST [394116] CONTEXT: writing block 23 of relation base/1653520455/1653526563_fsm > WAL redo at 7C5B/83944978 for Heap/UPDATE: off 126 xmax 1873090085 flags 0x02 ; new off 3 xmax 0 > 2023-05-26 03:30:30.438 MST [394116] WARNING: xlog min recovery request 7C5B/8AC06EA0 is past current point 7C5B/8847C348 > 2023-05-26 03:30:30.438 MST [394116] CONTEXT: writing block 23 of relation base/1653520455/1653526563_fsm > WAL redo at 7C5B/8847A420 for XLOG/FPI_FOR_HINT: > 2023-05-26 03:30:33.612 MST [394116] WARNING: xlog min recovery request 7C5B/BD1CC550 is past current point 7C5B/8A3CF248 > 2023-05-26 03:30:33.612 MST [394116] CONTEXT: writing block 2 of relation base/1653520455/1653527229_fsm > WAL redo at 7C5B/8A3CF208 for Heap2/VISIBLE: cutoff xid 1873088629 flags 0x01 > 2023-05-26 03:30:42.836 MST [394116] WARNING: xlog min recovery request 7C5B/BA11C7D8 is past current point 7C5B/8C7830E8 > 2023-05-26 03:30:42.836 MST [394116] CONTEXT: writing block 0 of relation base/1653520455/1653554782_vm > WAL redo at 7C5B/8C7830B0 for Heap2/CLEAN: remxid 1873090422 > 2023-05-26 03:30:48.174 MST [394116] WARNING: xlog min recovery request 7C5C/3E4F06F8 is past current point 7C5B/8EC92C70 > 2023-05-26 03:30:48.174 MST [394116] CONTEXT: writing block 126 of relation base/1653520455/1653524986_fsm > WAL redo at 7C5B/8EC92B90 for Heap2/CLEAN: remxid 1873087613 > > > Eventually the cluster reached the consistent state and reported > "ready to accept connections" but I'm wondering what could have caused > these messages and what they are about. Googling did not bring much > enlightenment. > > Most of these messages seem to be about the FSMs, but not all of them. > > Any ideas? Should I be worried? The relevant code comment says that corrupted heap pages could be the cause. [0] But searching the lists I found [1] which names the visibility map code as one cause. But this is just a guess, I don't know if that explanation is still valid. [0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/transam/xlog.c;h=a1ceded9e092f40e2559a020bd9675856a428edb;hb=2faab87390b03929a8cbb5a9336a04faa45a27c5#l2823 [1] https://www.postgresql.org/message-id/CAB7nPqTQkW%2BFZYQbbPBoaoge1HkQCD7gxKfGGigF6E88mvYKfw%40mail.gmail.com > The basebackup command was very simple, I was actually making a copy > of the running cluster for experimental purposes to another zpool: > > pg_basebackup -D /pg_data0/13/test2 -c fast -X stream -U repmgr -P -- Erik