Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1tk72B-00099k-Bm
	for pgsql-bugs@arkaria.postgresql.org; Mon, 17 Feb 2025 19:44:03 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1tk729-002Byc-GM
	for pgsql-bugs@arkaria.postgresql.org; Mon, 17 Feb 2025 19:44:01 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1tk729-002ByI-8S
	for pgsql-bugs@lists.postgresql.org; Mon, 17 Feb 2025 19:44:01 +0000
Received: from sss.pgh.pa.us ([68.162.161.243])
	by makus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1tk727-001NRk-23
	for pgsql-bugs@lists.postgresql.org;
	Mon, 17 Feb 2025 19:44:00 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 51HJhv1c906546;
	Mon, 17 Feb 2025 14:43:57 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sergey Belyashov <sergey.belyashov@gmail.com>
cc: pgsql-bugs@lists.postgresql.org, Tomas Vondra <tomas@vondra.me>
Subject: Re: BUG #18815: Logical replication worker Segmentation fault
In-reply-to: 
 <CAOe0RDwbowSGv8qeuqyHzJndtwV5JyPEG4YwmaAvgquC=gjz+Q@mail.gmail.com>
References: <18815-2a0407cc7f40b327@postgresql.org>
 <832225.1739810351@sss.pgh.pa.us>
 <CAOe0RDwbowSGv8qeuqyHzJndtwV5JyPEG4YwmaAvgquC=gjz+Q@mail.gmail.com>
Comments: In-reply-to Sergey Belyashov <sergey.belyashov@gmail.com>
	message dated "Mon, 17 Feb 2025 22:17:05 +0300"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <906376.1739821322.0@sss.pgh.pa.us>
Date: Mon, 17 Feb 2025 14:43:57 -0500
Message-ID: <906545.1739821437@sss.pgh.pa.us>
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>
Archived-At: 
 <https://www.postgresql.org/message-id/906545.1739821437%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <906376.1739821322.1@sss.pgh.pa.us>

Sergey Belyashov <sergey.belyashov@gmail.com> writes:
> I think backtrace will help.
> Core was generated by `postgres: 17/main: logical replication apply
> worker for subscription 602051860'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00005635402c869c in brinRevmapTerminate (revmap=0x0)
>     at ./build/../src/backend/access/brin/brin_revmap.c:102
> (gdb) backtrace
> #0  0x00005635402c869c in brinRevmapTerminate (revmap=0x0)
>     at ./build/../src/backend/access/brin/brin_revmap.c:102
> #1  0x00005635402bfddd in brininsertcleanup (index=<optimized out>,
> indexInfo=<optimized out>)
>     at ./build/../src/backend/access/brin/brin.c:515
> #2  0x0000563540479309 in ExecCloseIndices
> (resultRelInfo=resultRelInfo@entry=0x563541cab8d0)
>     at ./build/../src/backend/executor/execIndexing.c:248

Thanks!  It seems clear from that that the fault is basically in
brininsertcleanup(), which is trashing the BrinInsertState but
leaving indexInfo->ii_AmCache still pointing at it, so that
the next brininsert() will think it has a valid cache entry.
I suspect that the attached will fix it.  What I don't understand
is why it's apparently so hard to trigger the crash, because it
looks to me like any two successive insert commands on the same
BRIN index should hit this.

BTW, I'm also a bit suspicious of the comment's claim that the
brinDesc doesn't need cleanup.  That looks like a potential
memory leak.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="fix-brininsertcleanup.patch";
	charset="us-ascii"
Content-ID: <906376.1739821322.2@sss.pgh.pa.us>
Content-Description: fix-brininsertcleanup.patch

diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index 4265687afa..60320440fc 100644
--- a/src/backend/access/brin/brin.c
+++ b/src/backend/access/brin/brin.c
@@ -511,16 +511,18 @@ brininsertcleanup(Relation index, IndexInfo *indexInfo)
 	BrinInsertState *bistate = (BrinInsertState *) indexInfo->ii_AmCache;
 
 	/* bail out if cache not initialized */
-	if (indexInfo->ii_AmCache == NULL)
+	if (bistate == NULL)
 		return;
 
+	/* do this first to avoid dangling pointer if we fail partway through */
+	indexInfo->ii_AmCache = NULL;
+
 	/*
 	 * Clean up the revmap. Note that the brinDesc has already been cleaned up
 	 * as part of its own memory context.
 	 */
 	brinRevmapTerminate(bistate->bis_rmAccess);
-	bistate->bis_rmAccess = NULL;
-	bistate->bis_desc = NULL;
+	pfree(bistate);
 }
 
 /*

------- =_aaaaaaaaaa0--