All the extensions installed in this database are these:
```
List of installed extensions
Name | Version | Schema |
Description
--------------------+---------+------------+-----------------------------------------------------------
amcheck | 1.3 | public | functions for verifying
relation integrity
btree_gist | 1.6 | public | support for indexing common
datatypes in GiST
pg_stat_statements | 1.9 | public | track execution statistics of
all SQL statements executed
pgcrypto | 1.3 | public | cryptographic functions
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(5 rows)
```
I tried to execute a query with parameters the query was supposed to be run
(because I'm not sure exactly the values in the where clause that made the
segmentation fault).
here is the explain: https://explain.depesz.com/s/Tql3 (Ps: I just had to
suppress the real table/index names)
Looks like since I've disable *jit* as Boris told, until now the database
did not restarted again... (not sure if it's coincidence)
On Mon, Nov 7, 2022 at 4:38 PM Tom Lane <[email protected]> wrote:
> Willian Colognesi <[email protected]> writes:
> > `I take it things were okay with the version you used previously?`
>
> > Yes, it was working pretty well in another instance with pg version
> > `12.4-1.pgdg18.04+1`, and we had to make a migration of one database that
> > was running in this server to another using Logical Replication.
>
> 12.4 to 14.5 is kind of a big jump :-(.
>
> The stack trace seems to indicate that ExecProcNode transferred control
> to never-never land, which says that something clobbered the function
> pointer it's trying to indirect through. I don't recall having seen
> any similar reports though.
>
> Are you using any extensions besides those that come with core Postgres?
> A build incompatibility with some third-party extension might explain
> this, perhaps.
>
> One thing I'm curious about is that the stack trace seems to imply that
> there was an Append plan node immediately below another Append. That
> shouldn't happen AFAIK --- the planner tries to collapse out such
> cases. Can you get us an EXPLAIN for the problem query?
>
> regards, tom lane
>
--
<http://www.trimble.com/>
*Willian Cezar de O. Colognesi*
Systems Analysis Specialist, Trimble Transportation Brazil
Avenida Santos Dumont, 271 | Londrina, PR | 86039-090
