Willian Colognesi writes:
> Looks like we can confirm that the jit disable fixed the problem, because
> since yesterday when I disabled jit, the database did not restarted again,
> and before it the database was restarting at least once per hour.
Hmm. I now recall that we had a previous report o
Looks like we can confirm that the jit disable fixed the problem, because
since yesterday when I disabled jit, the database did not restarted again,
and before it the database was restarting at least once per hour.
I don't think it will cause too much impact in our use case having it
disabled, so,
You are right Thomas,
Just confirmed and it's installed:
ubuntu@ip-10-x-x-x:~$ apt search llvm | grep inst
WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.
libllvm10/focal,now 1:10.0.0-4ubuntu1 arm64 [installed,automatic]
I was trying something like `llvm -version`
On Tue, Nov 8, 2022 at 11:45 AM Willian Colognesi
wrote:
> root@ip-10-x-x-x:/home/ubuntu# pg_config --configure
> ... --with-extra-version= (Ubuntu 14.5-2.pgdg20.04+2)' ...
> ... '--with-llvm' 'LLVM_CONFIG=/usr/bin/llvm-config-10' ...
> There is no llvm installed on ubuntu server, postgresql was
On Mon, Nov 7, 2022 at 2:38 PM Tom Lane wrote:
>
> Willian Colognesi 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 th
Willian Colognesi writes:
> There is no llvm installed on ubuntu server, postgresql was installed via
> apt package `apt install postgresql-14`
If there's no LLVM around, then disabling JIT wouldn't do anything,
because it depends on LLVM to compile code.
We should perhaps wait awhile to see if
Do you mean how it was compiled? the output of pg_config is it:
```
root@ip-10-x-x-x:/home/ubuntu# pg_config --configure
'--build=aarch64-linux-gnu' '--prefix=/usr'
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir
Willian Colognesi writes:
> No, the database is running well, no problem until now after disabled *jit.*
Interesting. Which version of LLVM is installed?
regards, tom lane
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
```
On Mon, Nov 7, 2022 at 5:25 PM Adrian Klave
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
+-+---
All the extensions installed in this database are these:
```
List of installed extensions
Name| Version | Schema |
Description
+-++---
amcheck
Willian Colognesi 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 Re
On 11/7/22 11:03 AM, Willian Colognesi wrote:
No, the origin where the database was was running ubuntu 18.04.5 x86_64
and the destination ubuntu 20.04.5 aarch64
Where I was going was this:
https://wiki.postgresql.org/wiki/Locale_data_changes
Then I realized you had not done any binary upgrade
No, the origin where the database was was running ubuntu 18.04.5 x86_64 and
the destination ubuntu 20.04.5 aarch64
On Mon, Nov 7, 2022 at 4:00 PM Adrian Klaver
wrote:
> On 11/7/22 10:57 AM, Willian Colognesi wrote:
> > 1) What versions of pg_dump and pg_restore did you use?
> > A: pg_dump and pg
On 11/7/22 10:57 AM, Willian Colognesi wrote:
1) What versions of pg_dump and pg_restore did you use?
A: pg_dump and pg_restore was done using pg 14 (the same as the
destination was running)
2) To be clear the subscription was started after the restore?
A: Yes
3) Where there any error message
1) What versions of pg_dump and pg_restore did you use?
A: pg_dump and pg_restore was done using pg 14 (the same as the destination
was running)
2) To be clear the subscription was started after the restore?
A: Yes
3) Where there any error messages issued at any point in below?
A: no errors durin
On 11/7/22 10:36 AM, Willian Colognesi wrote:
Hi Tom,
`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 a
Hi Tom,
`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.
the process was
Willian Colognesi writes:
> I started to use version `14.5-2.pgdg20.04+2` for a dedicated database and
> I'm facing many segmentation faults during the day when the database has
> more heavy queries.
I take it things were okay with the version you used previously?
What was that exactly? Has anyt
Hello!
I started to use version `14.5-2.pgdg20.04+2` for a dedicated database and
I'm facing many segmentation faults during the day when the database has
more heavy queries.
The server log there are many of this:
```
2022-11-07 17:23:19.423 UTC [728] LOG: background worker "parallel worker"
(PI
20 matches
Mail list logo
