From pryzbyj@telsasoft.com Fri Jul  10 15:53:30 2026
From: Justin Pryzby <pryzbyj@telsasoft.com>
Date: Thu, 19 Nov 2020 20:48:48 -0600
Subject: [PATCH 1/2] bootstrap: convert Typ to a List*

---
 src/backend/bootstrap/bootstrap.c | 89 ++++++++++++++-----------------
 1 file changed, 41 insertions(+), 48 deletions(-)

diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 6f615e6622..1b940d9d27 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -58,7 +58,7 @@ static void BootstrapModeMain(void);
 static void bootstrap_signals(void);
 static void ShutdownAuxiliaryProcess(int code, Datum arg);
 static Form_pg_attribute AllocateAttribute(void);
-static void populate_typ_array(void);
+static void populate_typ(void);
 static Oid	gettype(char *type);
 static void cleanup(void);
 
@@ -159,7 +159,7 @@ struct typmap
 	FormData_pg_type am_typ;
 };
 
-static struct typmap **Typ = NULL;
+static List *Typ = NIL; /* List of struct typmap* */
 static struct typmap *Ap = NULL;
 
 static Datum values[MAXATTR];	/* current row's attribute values */
@@ -595,10 +595,10 @@ boot_openrel(char *relname)
 
 	/*
 	 * pg_type must be filled before any OPEN command is executed, hence we
-	 * can now populate the Typ array if we haven't yet.
+	 * can now populate Typ if we haven't yet.
 	 */
-	if (Typ == NULL)
-		populate_typ_array();
+	if (Typ == NIL)
+		populate_typ();
 
 	if (boot_reldesc != NULL)
 		closerel(NULL);
@@ -688,7 +688,7 @@ DefineAttr(char *name, char *type, int attnum, int nullness)
 
 	typeoid = gettype(type);
 
-	if (Typ != NULL)
+	if (Typ != NIL)
 	{
 		attrtypes[attnum]->atttypid = Ap->am_oid;
 		attrtypes[attnum]->attlen = Ap->am_typ.typlen;
@@ -866,47 +866,36 @@ cleanup(void)
 }
 
 /* ----------------
- *		populate_typ_array
+ *		populate_typ
  *
- * Load the Typ array by reading pg_type.
+ * Load Typ by reading pg_type.
  * ----------------
  */
 static void
-populate_typ_array(void)
+populate_typ(void)
 {
 	Relation	rel;
 	TableScanDesc scan;
 	HeapTuple	tup;
-	int			nalloc;
-	int			i;
-
-	Assert(Typ == NULL);
+	MemoryContext old;
 
-	nalloc = 512;
-	Typ = (struct typmap **)
-		MemoryContextAlloc(TopMemoryContext, nalloc * sizeof(struct typmap *));
+	Assert(Typ == NIL);
 
 	rel = table_open(TypeRelationId, NoLock);
 	scan = table_beginscan_catalog(rel, 0, NULL);
-	i = 0;
+	old = MemoryContextSwitchTo(TopMemoryContext);
 	while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL)
 	{
 		Form_pg_type typForm = (Form_pg_type) GETSTRUCT(tup);
+		struct typmap *newtyp;
 
-		/* make sure there will be room for a trailing NULL pointer */
-		if (i >= nalloc - 1)
-		{
-			nalloc *= 2;
-			Typ = (struct typmap **)
-				repalloc(Typ, nalloc * sizeof(struct typmap *));
-		}
-		Typ[i] = (struct typmap *)
-			MemoryContextAlloc(TopMemoryContext, sizeof(struct typmap));
-		Typ[i]->am_oid = typForm->oid;
-		memcpy(&(Typ[i]->am_typ), typForm, sizeof(Typ[i]->am_typ));
-		i++;
+		newtyp = (struct typmap *) palloc(sizeof(struct typmap));
+		Typ = lappend(Typ, newtyp);
+
+		newtyp->am_oid = typForm->oid;
+		memcpy(&newtyp->am_typ, typForm, sizeof(newtyp->am_typ));
 	}
-	Typ[i] = NULL;				/* Fill trailing NULL pointer */
+	MemoryContextSwitchTo(old);
 	table_endscan(scan);
 	table_close(rel, NoLock);
 }
@@ -916,25 +905,26 @@ populate_typ_array(void)
  *
  * NB: this is really ugly; it will return an integer index into TypInfo[],
  * and not an OID at all, until the first reference to a type not known in
- * TypInfo[].  At that point it will read and cache pg_type in the Typ array,
+ * TypInfo[].  At that point it will read and cache pg_type in Typ,
  * and subsequently return a real OID (and set the global pointer Ap to
  * point at the found row in Typ).  So caller must check whether Typ is
- * still NULL to determine what the return value is!
+ * still NIL to determine what the return value is!
  * ----------------
  */
 static Oid
 gettype(char *type)
 {
-	if (Typ != NULL)
+	if (Typ != NIL)
 	{
-		struct typmap **app;
+		ListCell *lc;
 
-		for (app = Typ; *app != NULL; app++)
+		foreach (lc, Typ)
 		{
-			if (strncmp(NameStr((*app)->am_typ.typname), type, NAMEDATALEN) == 0)
+			struct typmap *app = lfirst(lc);
+			if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0)
 			{
-				Ap = *app;
-				return (*app)->am_oid;
+				Ap = app;
+				return app->am_oid;
 			}
 		}
 	}
@@ -949,7 +939,7 @@ gettype(char *type)
 		}
 		/* Not in TypInfo, so we'd better be able to read pg_type now */
 		elog(DEBUG4, "external type: %s", type);
-		populate_typ_array();
+		populate_typ();
 		return gettype(type);
 	}
 	elog(ERROR, "unrecognized type \"%s\"", type);
@@ -977,17 +967,20 @@ boot_get_type_io_data(Oid typid,
 					  Oid *typinput,
 					  Oid *typoutput)
 {
-	if (Typ != NULL)
+	if (Typ != NIL)
 	{
 		/* We have the boot-time contents of pg_type, so use it */
-		struct typmap **app;
-		struct typmap *ap;
-
-		app = Typ;
-		while (*app && (*app)->am_oid != typid)
-			++app;
-		ap = *app;
-		if (ap == NULL)
+		struct typmap *ap = NULL;
+		ListCell *lc;
+
+		foreach (lc, Typ)
+		{
+			ap = lfirst(lc);
+			if (ap->am_oid == typid)
+				break;
+		}
+
+		if (!ap || ap->am_oid != typid)
 			elog(ERROR, "type OID %u not found in Typ list", typid);
 
 		*typlen = ap->am_typ.typlen;
-- 
2.17.0


--yQbNiKLmgenwUfTN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="0002-Allow-composite-types-in-bootstrap.patchx"



From anthonin.bonnefoy@datadoghq.com Fri May  15 23:38:34 2026
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-hackers-owner+archive@lists.postgresql.org>)
	id 1sh28w-00Bxaq-NA
	for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Aug 2024 07:22:02 +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-hackers-owner+archive@lists.postgresql.org>)
	id 1sh28t-0002Nf-N4
	for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Aug 2024 07:22:00 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <anthonin.bonnefoy@datadoghq.com>)
	id 1sh28t-0002NW-Bn
	for pgsql-hackers@lists.postgresql.org; Thu, 22 Aug 2024 07:21:59 +0000
Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536])
	by magus.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <anthonin.bonnefoy@datadoghq.com>)
	id 1sh28m-000uWK-0c
	for pgsql-hackers@postgresql.org; Thu, 22 Aug 2024 07:21:59 +0000
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5bef295a45bso539626a12.0
        for <pgsql-hackers@postgresql.org>; Thu, 22 Aug 2024 00:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=datadoghq.com; s=google; t=1724311311; x=1724916111; darn=postgresql.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=kVMeiWZ3ATtGdEqkGNIyoKt7TE3hhx4ZOHPu4ZM8DOs=;
        b=NG8XnRIGcakJXpo4NEBvQJa88qFN8MDnBj1DjJ7C/u5fPw29MUa/OvtZm/IDJoCMFK
         FPGIY6y5v+zdMNSWf57SzHBCB0BOhKw/Zi9MEbJfdjzmCCeHUj746A9hviZJgdLuabht
         8bfc/sbW60hFfNDLMUnsavYTdKgwOnu+cskf4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724311311; x=1724916111;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=kVMeiWZ3ATtGdEqkGNIyoKt7TE3hhx4ZOHPu4ZM8DOs=;
        b=EvjgCKPJdyovnblEBEmWofRH5hq0e6Y8GZmqBTYUU1C2VK2q45xokzUD57a8Q8hl75
         ppcMrJCyPMfowW7/yoRRwQ4YK+PvxRAadH1h2ScPR1El/rISj+BnCYKbH31gmyWiLTqb
         V93HoChksdp4nRi76j+aH6XxU0lT6DanUaNQAb2PwqgQigLgsaCumhybHBBzL94LcTWk
         7a8Pk6DhNlh5pimh9UHTVBu6DPD5gzLkbl316lS8PsKDbvr2Wdk9lLNABTSLGo0E0Lt4
         w7peI+Xdgtko2I9vzKgphly6V1MniB0JSNDQzIsGDXy1vlbG9/bqwyGoIjU3fSqL2w93
         lihg==
X-Gm-Message-State: AOJu0YyZF1SLAsVbfBOhXcypuqDniLRkAw1xe43NhETEuxkAcTrxPHCY
	IQFSN4Lgi53sUfihxD1jVhjK4snSJnQ099bszDXziwN25s/PT9FBBWR9uci5RhHT+3pt4YXDx5l
	7pKSM4r5V8mReLRKP+hVjTWCANzMenXVX532VpJwjOyxbO8i3m+w=
X-Google-Smtp-Source: AGHT+IHirmvBcvPvcWu+2rfI93RUx5xZSmcxGzXin4AZI5cn5Docy9KJn8JOfB4qU7lpV6pcZroMHrP2VIDQUUzx1I4=
X-Received: by 2002:a05:6402:3714:b0:5bf:16d:197 with SMTP id
 4fb4d7f45d1cf-5c07920da19mr952476a12.21.1724311310910; Thu, 22 Aug 2024
 00:21:50 -0700 (PDT)
MIME-Version: 1.0
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Date: Thu, 22 Aug 2024 09:21:39 +0200
Message-ID: <CAO6_Xqr63qj=Sx7HY6ZiiQ6R_JbX+-p6sTPwDYwTWZjUmjsYBg@mail.gmail.com>
Subject: Segfault in jit tuple deforming on arm64 due to LLVM issue
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/CAO6_Xqr63qj%3DSx7HY6ZiiQ6R_JbX%2B-p6sTPwDYwTWZjUmjsYBg%40mail.gmail.com>
Precedence: bulk

Hi!

I have an instance that started to consistently crash with segfault or
bus error and most of the generated coredumps had corrupted stacks.
Some salvageable frames showed the error happening within
ExecRunCompiledExpr. Sure enough, running the query with jit disabled
stopped the crashes. The issue happens with the following setup:

Ubuntu jammy on arm64, 30G
postgresql-14 14.12-1.pgdg22.04+1
libllvm15 1:15.0.7-0ubuntu0.22.04.3

I was able to isolate the impacted database the db (pg_dump of the
table was not enough, a base backup had to be used) and reproduce the
issue on a debug build of PostgresSQL. This time, there's no crash but
it was stuck in an infinite loop within jit tuple deforming:

#0  0x0000ec53660aa14c in deform_0_1 ()
#1  0x0000ec53660aa064 in evalexpr_0_0 ()
#2  0x0000ab8f9b322948 in ExecEvalExprSwitchContext
(isNull=0xfffff47c3c87, econtext=0xab8fd0f13878, state=0xab8fd0f13c50)
at executor/./build/../src/include/executor/executor.h:342
#3  ExecProject (projInfo=0xab8fd0f13c48) at
executor/./build/../src/include/executor/executor.h:376

Looking at the generated assembly, the infinite loop happens between
deform_0_1+140 and deform_0_1+188

// Store address page in x11 register
0xec53660aa130 <deform_0_1+132> adrp    x11, 0xec53fd308000
// Start of the infinite loop
0xec53660aa138 <deform_0_1+140> adr     x8, 0xec53660aa138 <deform_0_1+140>
// Load the content of 0xec53fd308000[x12] in x10, x12 was 0 at that time
0xec53660aa13c <deform_0_1+144> ldrsw   x10, [x11, x12, lsl #2]
// Add the loaded offset to x8
0xec53660aa140 <deform_0_1+148> add     x8, x8, x10
...
// Branch to address in x8. Since x10 was 0, x8 has the value
deform_0_1+140, creating the infinite loop
0xec53660aa168 <deform_0_1+188> br      x8

Looking at the content of 0xec53fd308000, We only see 0 values stored
at the address.

x/6 0xec53fd308000
0xec53fd308000: 0x00000000      0x00000000      0x00000000      0x00000000
0xec53fd308010: 0x00000000      0x00000000

The assembly matches the code for the find_start switch case in
llvmjit_deform[1]. The content at the address 0xec53fd308000 should
contain the offset table from the PC to branch to the correct
attcheckattnoblocks block. As a comparison, if I execute a query not
impacted by the issue (the size of the jit compiled module seems to be
a factor), I can see that the offset table was correctly filled.

x/6 0xec55fd30700
0xec55fd307000: 0x00000060      0x00000098      0x000000e8      0x00000170
0xec55fd307010: 0x0000022c      0x000002e8

I was suspecting something was erasing the content of the offset table
so I've checked with rr. However, it was only initialized and nothing
was written at this memory address. I was starting to suspect a
possible LLVM issue and ran the query against a debug build of
llvm_jit. It immediately triggered the following assertion[2]:

void llvm::RuntimeDyldELF::resolveAArch64Relocation(const
llvm::SectionEntry &, uint64_t, uint64_t, uint32_t, int64_t):
Assertion `isInt<33>(Result) && "overflow check failed for
relocation"' failed.

This happens when LLVM is resolving relocations.

#5  __GI___assert_fail (assertion=0xf693f214771a "isInt<33>(Result) &&
\"overflow check failed for relocation\"", file=0xf693f2147269
"/var/lib/postgresql/llvm-project/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp",
line=507, function=0xf693f214754f "void
llvm::RuntimeDyldELF::resolveAArch64Relocation(const
llvm::SectionEntry &, uint64_t, uint64_t, uint32_t, int64_t)") at
./assert/assert.c:101
#6  llvm::RuntimeDyldELF::resolveAArch64Relocation () at
/var/lib/postgresql/llvm-project/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:507
#7  llvm::RuntimeDyldELF::resolveRelocation () at
/var/lib/postgresql/llvm-project/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:1044
#8  llvm::RuntimeDyldELF::resolveRelocation () at
/var/lib/postgresql/llvm-project/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:1026
#9  llvm::RuntimeDyldImpl::resolveRelocationList () at
/var/lib/postgresql/llvm-project/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:1112
#10 llvm::RuntimeDyldImpl::resolveLocalRelocations () at
/var/lib/postgresql/llvm-project/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:157
#11 llvm::RuntimeDyldImpl::finalizeAsync() at
/var/lib/postgresql/llvm-project/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:1247

During the assertion failure, I have the following values:
Value: 0xfbc84fab9000
FinalAddress: 0xfbc5b9cea12c
Addend: 0x0
Result: 0x295dcf000

The result is indeed greater than an int32, triggering the assert.
Looking at the sections created by LLVM in allocateSection[3], we have
3 sections created:
.text     {Address = 0xfbc5b9cea000, AllocatedSize = 90112}
.rodata   {Address = 0xfbc84fab9000, AllocatedSize = 4096}
.eh_frame {Address = 0xfbc84fab7000, AllocatedSize = 8192}

When resolving relocation, the difference between the rodata section
and the PC is computed and stored in the ADRP instruction. However,
when a new section is allocated, LLVM will request a new memory block
from the memory allocator[4]. The MemGroup.Near is passed as the start
hint of mmap but that's only a hint and the kernel doesn't provide any
guarantee that the new allocated block will be near. With the impacted
query, there are more than 10GB of gap between the .text section and
the .rodata section, making it impossible for the code in the .text
section to correctly fetch data from the .rodata section as the
address in ADRP is limited to a +/-4GB range.

There are mentions about this in the ABI that the GOT section should
be within 4GB from the text section[5]. Though in this case, there's
no GOT section as the offsets are stored in the .rodata section but
the constraint is going to be similar. This is a known LLVM issue[6]
that impacted Impala, Numba and Julia. There's an open PR[7] to fix
the issue by allocating all sections as a single memory block,
avoiding the gaps between sections. There's also a related discussion
on this on llvm-rtdyld discourse[8].

A possible mitigation is to switch from RuntimeDyld to JITLinking but
this requires at least LLVM15 as LLVM14 doesn't have any significant
relocation support for aarch64[9]. I did test using JITLinking on my
impacted db and it seems to fix the issue. JITLinking has no exposed C
interface though so it requires additional wrapping.

I don't necessarily have a good answer for this issue. I've tried to
tweak relocation settings or the jit code to avoid relocation without
too much success. Ideally, the llvm fix will be merged and backported
in llvm but the PR has been open for some time now. I've seen multiple
segfault reports that look similar to this issue (example: [10], [11])
but I don't think it was linked to the LLVM bug so I figured I would
at least share my findings.

[1] https://github.com/postgres/postgres/blob/REL_14_STABLE/src/backend/jit/llvm/llvmjit_deform.c#L364-L382
[2] https://github.com/llvm/llvm-project/blob/release/14.x/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp#L501-L513
[3] https://github.com/llvm/llvm-project/blob/release/14.x/llvm/lib/ExecutionEngine/SectionMemoryManager.cpp#L41C32-L41C47
[4] https://github.com/llvm/llvm-project/blob/release/14.x/llvm/lib/ExecutionEngine/SectionMemoryManager.cpp#L94-L110
[5] https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst#7code-models
[6] https://github.com/llvm/llvm-project/issues/71963
[7] https://github.com/llvm/llvm-project/pull/71968
[8] https://discourse.llvm.org/t/llvm-rtdyld-aarch64-abi-relocation-restrictions/74616
[9] https://github.com/llvm/llvm-project/blob/release/14.x/llvm/lib/ExecutionEngine/JITLink/ELF_aarch64.cpp#L75-L84
[10] https://www.postgresql.org/message-id/flat/CABa%2BnRvwZy_5t1QF9NJNGwAf03tv_PO_Sg1FsN1%2B-3Odb1XgBA%40mail.gmail.com
[11] https://www.postgresql.org/message-id/flat/CADAf1kavcN-kY%3DvEm3MYxhUa%2BrtGFs7tym5d7Ee6Ni2cwwxGqQ%40mail.gmail.com

Regards,
Anthonin Bonnefoy






From thomas.munro@gmail.com Fri May  15 23:47:42 2026
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-hackers-owner+archive@lists.postgresql.org>)
	id 1sh59C-00CeOR-Ve
	for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Aug 2024 10:34:30 +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-hackers-owner+archive@lists.postgresql.org>)
	id 1sh58C-001GKZ-C8
	for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Aug 2024 10:33:28 +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 <thomas.munro@gmail.com>)
	id 1sh58C-001GKQ-2S
	for pgsql-hackers@lists.postgresql.org; Thu, 22 Aug 2024 10:33:28 +0000
Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f])
	by makus.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <thomas.munro@gmail.com>)
	id 1sh586-000sx5-9d
	for pgsql-hackers@postgresql.org; Thu, 22 Aug 2024 10:33:27 +0000
Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a7aa74d1ab8so3244866b.1
        for <pgsql-hackers@postgresql.org>; Thu, 22 Aug 2024 03:33:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1724322801; x=1724927601; darn=postgresql.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=KEq7wngwwHMMWSUE6AypgiMVx9m8apHHQl7KQjQv4BY=;
        b=gqp09SzGY3hsYIpBOr/BdoWfTh07EQH/Mdc6x1LRLTCBbkZslXKEUvkQAqK+2ZKSkM
         gWFTT6Q1NAyZ5Gi07/K/Yzaad3skrGpgyKMzHTueOcSJ4dHsp+XodDKcPP5RRoaFLsc2
         AqPdbcm2oExXMekE7AmWc07WFtwylTMG+EqU3UCPxFRI6Z5r5Uepx479VzDt/B96775n
         fvnPTi7Y8AkSwBqODbN/O4rCkMk5o553Un7z5UJHoL/6t73mRE+656XWy/cDoJJVv4Qe
         5oFa2ziEoQ6Pgo099nFpdoOloF0Os6EvxvKhe+HUZNqBnp82ODnpTnEnt1XgZqXzB2Dp
         tu9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724322801; x=1724927601;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=KEq7wngwwHMMWSUE6AypgiMVx9m8apHHQl7KQjQv4BY=;
        b=N7b5vWL7O6hOKX8cTlZEYmkC8AqCp55RiF8H5FHNeK5XxGFxAbPtj50XheITBwcx0X
         Bp02gjWLIK2ZBb5LVvmCc6v/2YlbM6HBb5BKZBpPQm6/I5gNM9dWpgBZR+exFJRVbie7
         t/jUxR9+2zzD+zCqt/wjPPEe98Q9k+ZYaR+lTlzdgMkiAMWNspbGJ9yB/GAtJFgKx0rg
         ODqMABgPog56fj1AUgtcIsHgsxNo0PV5lFIuEBsWBz6og6ECuF55D+5RwydhDzh1RaAc
         5GDimOStdjJbm8qeLB5vKyDgVPC1XHOn/6JmfxHUVidrsWvQuxgtKiUZAP1rYk1LJStf
         w0IA==
X-Gm-Message-State: AOJu0YzBFJ36dxPy7IAYC2381zwkeUnmWkn3Hrz6a9BgigwSnecOzEkt
	Ts3fsFfrSalY3jZvJA2jkK4AOZtiuzrE2FF2YmZw9KgNqxwrCX9H+egSVPf4LK0BFTJJ9aFz32x
	PNfU+lUgRLmxOY626Oohl193X3uE=
X-Google-Smtp-Source: AGHT+IG5lnM/LVFsSvzhMF7HhjRXrBBmpsYzpL3ngpD0VAA8RFzmcIb26s74Rd8UM4fGMT8AYNnxPW2ApRQvlfgl15A=
X-Received: by 2002:a17:907:7210:b0:a7a:b895:6571 with SMTP id
 a640c23a62f3a-a866f9fac2bmr214578966b.9.1724322800274; Thu, 22 Aug 2024
 03:33:20 -0700 (PDT)
MIME-Version: 1.0
References: <CAO6_Xqr63qj=Sx7HY6ZiiQ6R_JbX+-p6sTPwDYwTWZjUmjsYBg@mail.gmail.com>
In-Reply-To: <CAO6_Xqr63qj=Sx7HY6ZiiQ6R_JbX+-p6sTPwDYwTWZjUmjsYBg@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Thu, 22 Aug 2024 22:32:41 +1200
Message-ID: <CA+hUKGLXt-_uSBCBfF=RicvZ4UxGTq_bzKeHSgPJnc6mGPYWbQ@mail.gmail.com>
Subject: Re: Segfault in jit tuple deforming on arm64 due to LLVM issue
To: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKGLXt-_uSBCBfF%3DRicvZ4UxGTq_bzKeHSgPJnc6mGPYWbQ%40mail.gmail.com>
Precedence: bulk

On Thu, Aug 22, 2024 at 7:22=E2=80=AFPM Anthonin Bonnefoy
<anthonin.bonnefoy@datadoghq.com> wrote:
> Ideally, the llvm fix will be merged and backported
> in llvm but the PR has been open for some time now.

I fear that back-porting, for the LLVM project, would mean "we fix it
in main/20.x, and also back-port it to 19.x".  Do distros back-port
further?

Nice detective work!

The JITLINK change sounds interesting, and like something we need to
do sooner or later.






From anthonin.bonnefoy@datadoghq.com Fri May  15 23:39:44 2026
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-hackers-owner+archive@lists.postgresql.org>)
	id 1shTJT-0025VA-UI
	for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Aug 2024 12:22:43 +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-hackers-owner+archive@lists.postgresql.org>)
	id 1shTJS-00CiFt-2P
	for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Aug 2024 12:22:42 +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 <anthonin.bonnefoy@datadoghq.com>)
	id 1shTJR-00CiFY-OL
	for pgsql-hackers@lists.postgresql.org; Fri, 23 Aug 2024 12:22:42 +0000
Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531])
	by makus.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <anthonin.bonnefoy@datadoghq.com>)
	id 1shTJP-0013gp-8p
	for pgsql-hackers@postgresql.org; Fri, 23 Aug 2024 12:22:40 +0000
Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-5bef295a2b4so3140915a12.0
        for <pgsql-hackers@postgresql.org>; Fri, 23 Aug 2024 05:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=datadoghq.com; s=google; t=1724415757; x=1725020557; darn=postgresql.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=TxRGpKg+NKzhZ6qyx399SDB65DFcrFX8Vdptb/vANX8=;
        b=g0cQo0GmH7ndspHIy5YSqI5pa3VMs/L5d+YRRmLE7fuE3TOlwYloX+S9qCfqhOMW90
         NVB9FZ2ILZ/Lj8TZd/RZeR7Lius5cN9nyxqnsx7Ln9FRn8fFJ2HoxUxq21646g0GDR01
         7D2lahc8/ULaEyrfDF04IERktoWwvTfZr6CHQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724415757; x=1725020557;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=TxRGpKg+NKzhZ6qyx399SDB65DFcrFX8Vdptb/vANX8=;
        b=cFrN/hrmKCN8Ph1/+d16YHUb9sy+/y6C037CKOFadmT/NsruaTdylyBFqa4pmeJ6xW
         M2Xqx/Mr9p8zPNva8I7lG8lQNTuWlvHvfCXqPhxUcawpm46Xy6sUuqfbiGs8OVzcHGQi
         CNgni+kXSI5TgikLNjQV1IUvzuoXQDIkQ8xmvKpyO/vWqarpRjcWDkeJptocIAcGtrXl
         D3qIdDS/kMYwjHxbdqs6OEp75beqBEFyOOBuP2re7/FFezGMkbR6+Te2YOkCsaIcu8le
         Ik0lx1TTp3PkmwoPD3cqgOvJft59R3UU1pwpglHPHwibFKD2TRJlf4qBreMHk66Bv/Bl
         yNXg==
X-Gm-Message-State: AOJu0Ywy7P+O6DYJXUT2qyzfMec+hI0wsLEh3IHeHXZziBG6njTFsbxV
	mlKCDGdsLVZOBJsFVaqwmhMpdu4LMFVPdoDjPmnJE8YKbyeAfUpBdljSuua5Uktpr3j5HYzzqGV
	//YaGpoiCnMbvfxtmL+UC0VZhYqtlUPfNfkCQjg==
X-Google-Smtp-Source: AGHT+IF6swZX/kvhMMpn9J50IzpWZ75+4YXbPBzvl8XOKn4gR2sBwZhx/qgCzrBbhwJC0RFv3G/qAkG8UG8qO72umMo=
X-Received: by 2002:a05:6402:2345:b0:5be:e9f8:9ba4 with SMTP id
 4fb4d7f45d1cf-5c088114571mr2560494a12.4.1724415757035; Fri, 23 Aug 2024
 05:22:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAO6_Xqr63qj=Sx7HY6ZiiQ6R_JbX+-p6sTPwDYwTWZjUmjsYBg@mail.gmail.com>
 <CA+hUKGLXt-_uSBCBfF=RicvZ4UxGTq_bzKeHSgPJnc6mGPYWbQ@mail.gmail.com>
In-Reply-To: <CA+hUKGLXt-_uSBCBfF=RicvZ4UxGTq_bzKeHSgPJnc6mGPYWbQ@mail.gmail.com>
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Date: Fri, 23 Aug 2024 14:22:25 +0200
Message-ID: <CAO6_XqptnQJb52sqpWVAy+9tag3HxQJrP7HEnCso_WZwZCxEgw@mail.gmail.com>
Subject: Re: Segfault in jit tuple deforming on arm64 due to LLVM issue
To: Thomas Munro <thomas.munro@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/CAO6_XqptnQJb52sqpWVAy%2B9tag3HxQJrP7HEnCso_WZwZCxEgw%40mail.gmail.com>
Precedence: bulk

On Thu, Aug 22, 2024 at 12:33=E2=80=AFPM Thomas Munro <thomas.munro@gmail.c=
om> wrote:
> I fear that back-porting, for the LLVM project, would mean "we fix it
> in main/20.x, and also back-port it to 19.x".  Do distros back-port
> further?

That's also my fear, I'm not familiar with distros back-port policy
but eyeballing ubuntu package changelog[1], it seems to be mostly
build fixes.

Given that there's no visible way to fix the relocation issue, I
wonder if jit shouldn't be disabled for arm64 until either the
RuntimeDyld fix is merged or the switch to JITLink is done. Disabling
jit tuple deforming may be enough but I'm not confident the issue
won't happen in a different part.

[1] https://launchpad.net/ubuntu/+source/llvm-toolchain-16/+changelog






From thomas.munro@gmail.com Fri May  15 23:51:23 2026
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-hackers-owner+archive@lists.postgresql.org>)
	id 1siPXi-003pyh-HP
	for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Aug 2024 02:33:18 +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-hackers-owner+archive@lists.postgresql.org>)
	id 1siPXf-003U44-Mp
	for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Aug 2024 02:33:16 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <thomas.munro@gmail.com>)
	id 1siPXf-003U3k-D6
	for pgsql-hackers@lists.postgresql.org; Mon, 26 Aug 2024 02:33:15 +0000
Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530])
	by magus.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <thomas.munro@gmail.com>)
	id 1siPXc-001VYN-3C
	for pgsql-hackers@postgresql.org; Mon, 26 Aug 2024 02:33:15 +0000
Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5bec23c0ba8so597537a12.2
        for <pgsql-hackers@postgresql.org>; Sun, 25 Aug 2024 19:33:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1724639592; x=1725244392; darn=postgresql.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JK0Y2/nXYESCSaPnjixme0VrRo1PIlXW1jrCeFl7HPU=;
        b=QPindbS8qdDA8zG3L6/RJJ4rShwzUNGRFEMgpDK6uUzc0/HoahCWN3Vgz+Gr0+N36b
         DABmEhUwWP2GCfYzZMRWtvIwDQQJOE0WnpGu/UTYANFSavarLyNx9/Bw8onh42lNT/Sv
         YRgBnRD8OutJJxkoRfq0N88Zk47QvwpiKP5MVgVk1q+/dmLXH8AwiEnPXDYQWnJ62r9n
         fUooD3FsBTGlAGbbMafs4WXEa9WQod91Cnewo3ofKB1HdyZwbD11RdF9MmVnU3OrnwYh
         Zu6bvCTX3GQKlCC5i2NKAobiOtV/yBK73+3KO9/esXiAV5dUk9u5B/txS0cUIGnKwE8h
         /lMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724639592; x=1725244392;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=JK0Y2/nXYESCSaPnjixme0VrRo1PIlXW1jrCeFl7HPU=;
        b=spnjo4LA9gxwYxUs7TMLx6PDr8E3kJWUjmSDPzQM4+jaUgeHM3gIBCoYIn4qFqioGW
         MP3QYcvbLR+eS8fyUjpKSvaxX4k+c7qiz+DNy8Qevzd2lGlw4P0A0rtiroIYoDsNfKXC
         asD1/bem5mi6emd6YrI2F1jG3Xl7GbIGcKTcaF0YRo4lbWUBlh17te7H8u/yiEsePYUr
         w0QEY0RiqyZmkzElOvYGV0c5VmsCRLfz4Qt+nAhFSv+YDIa1g5zJLQsoQXGKJrKIWaYA
         TdhDCBUf32hHLwUSo/axbVQ7HyfIGgNO3bo8pKgENXY949FDiDiM9zADTEp1yvN8Ckn7
         zXdQ==
X-Gm-Message-State: AOJu0Yxl7pllOifvSiEV/gDjO5ro+ponFE2M1bZSkgWcNaKYfjcXxa/f
	s/xK6cdN2EcAw1/ErYd0R8rp3aNW1vol/LJSyFRYrNEOGZ9gniM9UyfTLmM4dUlPo9khEdQ6O5n
	6Xic3EGgWWnCnNWT7XbM0j8P5ZyTycL3gkkE=
X-Google-Smtp-Source: AGHT+IFkQxrxGg6hD7AQFbdW2wxyHn27SP6a8c6ClpR6OUFfDZdJckawkuVXzkmyWGKvi9cNldw6A9f6KVqFcMC/q2I=
X-Received: by 2002:a17:907:6d09:b0:a80:a3a8:9867 with SMTP id
 a640c23a62f3a-a86a54da34emr339515666b.9.1724639591283; Sun, 25 Aug 2024
 19:33:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAO6_Xqr63qj=Sx7HY6ZiiQ6R_JbX+-p6sTPwDYwTWZjUmjsYBg@mail.gmail.com>
 <CA+hUKGLXt-_uSBCBfF=RicvZ4UxGTq_bzKeHSgPJnc6mGPYWbQ@mail.gmail.com> <CAO6_XqptnQJb52sqpWVAy+9tag3HxQJrP7HEnCso_WZwZCxEgw@mail.gmail.com>
In-Reply-To: <CAO6_XqptnQJb52sqpWVAy+9tag3HxQJrP7HEnCso_WZwZCxEgw@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Mon, 26 Aug 2024 14:32:34 +1200
Message-ID: <CA+hUKGL+rRGWneZ7+v0dkF-4yWPKoJU16XQ7Qg0j5sOYGwhRfg@mail.gmail.com>
Subject: Re: Segfault in jit tuple deforming on arm64 due to LLVM issue
To: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKGL%2BrRGWneZ7%2Bv0dkF-4yWPKoJU16XQ7Qg0j5sOYGwhRfg%40mail.gmail.com>
Precedence: bulk

On Sat, Aug 24, 2024 at 12:22=E2=80=AFAM Anthonin Bonnefoy
<anthonin.bonnefoy@datadoghq.com> wrote:
> On Thu, Aug 22, 2024 at 12:33=E2=80=AFPM Thomas Munro <thomas.munro@gmail=
.com> wrote:
> > I fear that back-porting, for the LLVM project, would mean "we fix it
> > in main/20.x, and also back-port it to 19.x".  Do distros back-port
> > further?
>
> That's also my fear, I'm not familiar with distros back-port policy
> but eyeballing ubuntu package changelog[1], it seems to be mostly
> build fixes.
>
> Given that there's no visible way to fix the relocation issue, I
> wonder if jit shouldn't be disabled for arm64 until either the
> RuntimeDyld fix is merged or the switch to JITLink is done. Disabling
> jit tuple deforming may be enough but I'm not confident the issue
> won't happen in a different part.

We've experienced something a little similar before: In the early days
of PostgreSQL LLVM, it didn't work at all on ARM or POWER.  We sent a
trivial fix[1] upstream that landed in LLVM 7; since it was a small
and obvious problem and it took a long time for some distros to ship
LLVM 7, we even contemplated hot-patching that LLVM function with our
own copy (but, ugh, only for about 7 nanoseconds).  That was before we
turned JIT on by default, and was also easier to deal with because it
was an obvious consistent failure in basic tests, so packagers
probably just disabled the build option on those architectures.  IIUC
this one is a random and rare crash depending on malloc() and perhaps
also the working size of your virtual memory dart board.  (Annoyingly,
I had tried to reproduce this quite a few times on small ARM systems
when earlier reports came in, d'oh!).

This degree of support window mismatch is probably what triggered RHEL
to develop their new rolling LLVM version policy.  Unfortunately, it's
the other distros that tell *us* which versions to support, and not
the reverse (for example CF #4920 is about to drop support for LLVM <
14, but that will only be for PostgreSQL 18+).

Ultimately, if it doesn't work, and doesn't get fixed, it's hard for
us to do much about it.  But hmm, this is probably madness... I wonder
if it would be feasible to detect address span overflow ourselves at a
useful time, as a kind of band-aid defence...

[1] https://www.postgresql.org/message-id/CAEepm%3D39F_B3Ou8S3OrUw%2BhJEUP3=
p%3DwCu0ug-TTW67qKN53g3w%40mail.gmail.com






