No, the database is running well, no problem until now after disabled jit.
I just realized that he send an email direct to me, the message was:
```
I had similar problems with and the cure was to turn off jit in Postgres.conf
jit = off
--
Boris
jit = off
--
Boris
```
On Mon, Nov 7, 2022 at 5:25 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
On 11/7/22 12:15, Willian Colognesi wrote:
> 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
> <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)
>
I did not see that post or suggestion.
What was the suggestion?
Are you saying the database does not start up now?
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
Willian Cezar de O. Colognesi
Systems Analysis Specialist, Trimble Transportation Brazil
