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 <t...@sss.pgh.pa.us> wrote:

> Willian Colognesi <willian_cologn...@trimble.com> 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

Reply via email to