Segmentation Fault PG 14

I started to use version `14.5-2.pgdg20.04+2` for a dedicated database and I'm facing many segmentation faults during the day when the database has more heavy queries.

The server log there are many of this:
```

2022-11-07 17:23:19.423 UTC [728] LOG:  background worker "parallel worker" (PID 9558) was terminated by signal 11: Segmentation fault
2022-11-07 17:23:19.423 UTC [728] DETAIL:  Failed process was running: select blablabla from heavyquery where ...;
2022-11-07 17:23:19.423 UTC [728] LOG:  terminating any other active server processes
2022-11-07 17:23:19.681 UTC [9588] microservice@microservice FATAL:  the database system is in recovery mode
2022-11-07 17:23:19.683 UTC [9589] microservice@microservice FATAL:  the database system is in recovery mode

2022-11-07 17:23:24.543 UTC [728] LOG:  all server processes terminated; reinitializing
2022-11-07 17:23:24.894 UTC [9622] LOG:  database system was interrupted; last known up at 2022-11-07 17:22:07 UTC

2022-11-07 17:23:25.636 UTC [9622] LOG:  invalid record length at 134/227A3A68: wanted 24, got 0
2022-11-07 17:23:25.636 UTC [9622] LOG:  redo done at 134/227A3A38 system usage: CPU: user: 0.04 s, system: 0.06 s, elapsed: 0.70 s
2022-11-07 17:23:27.608 UTC [728] LOG:  database system is ready to accept connections
2022-11-07 17:23:33.474 UTC [9635] replica@[unknown] LOG:  could not receive data from client: Connection reset by peer
2022-11-07 17:23:33.474 UTC [9635] replica@[unknown] STATEMENT:  START_REPLICATION 134/22000000 TIMELINE 1
2022-11-07 17:23:33.474 UTC [9635] replica@[unknown] LOG:  unexpected EOF on standby connection
2022-11-07 17:23:33.474 UTC [9635] replica@[unknown] STATEMENT:  START_REPLICATION 134/22000000 TIMELINE 1
2022-11-07 17:23:51.310 UTC [9662] replica@[unknown] LOG:  could not receive data from client: Connection reset by peer
2022-11-07 17:23:51.310 UTC [9662] replica@[unknown] STATEMENT:  START_REPLICATION 134/22000000 TIMELINE 1
2022-11-07 17:23:51.310 UTC [9662] replica@[unknown] LOG:  unexpected EOF on standby connection
2022-11-07 17:23:51.310 UTC [9662] replica@[unknown] STATEMENT:  START_REPLICATION 134/22000000 TIMELINE 1
INFO: 2022/11/07 17:23:51.445710 FILE PATH: 000000010000013400000022.lz4
2022-11-07 17:24:09.206 UTC [9672] replica@[unknown] LOG:  could not receive data from client: Connection reset by peer
2022-11-07 17:24:09.206 UTC [9672] replica@[unknown] STATEMENT:  START_REPLICATION 134/23000000 TIMELINE 1
2022-11-07 17:24:09.206 UTC [9672] replica@[unknown] LOG:  unexpected EOF on standby connection
2022-11-07 17:24:09.206 UTC [9672] replica@[unknown] STATEMENT:  START_REPLICATION 134/23000000 TIMELINE 1
INFO: 2022/11/07 17:24:27.527897 FILE PATH: 000000010000013400000023.lz4
INFO: 2022/11/07 17:24:38.076058 FILE PATH: 000000010000013400000024.lz4

```

It's server is running in ubuntu 22.04 in aarch64 (ARM architecture)

I could also get a little information from gdb, I'm not sure if it will help:

```
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/postgresql/14/bin/postgres...
Reading symbols from /usr/lib/debug/.build-id/d7/87a0cf1bb645b349f7c137e36cc30f7ba8805f.debug...
[New LWP 9559]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: 14/main: parallel worker for PID 9528                               '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000100000c757c9c in ?? ()
(gdb) bt
#0  0x000100000c757c9c in ?? ()
#1  0x0000ffff0c757124 in ?? ()
#2  0x0000aaaac2ac9970 in ExecProcNode (node=0xaaaafc599818) at ./build/../src/include/executor/executor.h:257
#3  ExecAppend (pstate=0xaaaafc595918) at ./build/../src/backend/executor/nodeAppend.c:360
#4  0x0000aaaac2ac9970 in ExecProcNode (node=0xaaaafc595918) at ./build/../src/include/executor/executor.h:257
#5  ExecAppend (pstate=0xaaaafc526988) at ./build/../src/backend/executor/nodeAppend.c:360
#6  0x0000000000000001 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

``` 

--