Search Postgresql Archives

Re: Segmentation Fault PG 14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <tgl@xxxxxxxxxxxxx> wrote:
Willian Colognesi <willian_colognesi@xxxxxxxxxxx> 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


--

Willian Cezar de O. Colognesi
Systems Analysis Specialist, Trimble Transportation Brazil
Avenida Santos Dumont, 271 | Londrina, PR | 86039-090


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux