Re: Segmentation Fault PG 14
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)
```
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@sss.pgh.pa.us> wrote:
Willian Colognesi <willian_colognesi@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
Willian Cezar de O. Colognesi
Systems Analysis Specialist, Trimble Transportation Brazil
В списке pgsql-general по дате отправления: