RE: segmentation fault

rotection -fcf-protection CFLAGS_SL = -fPIC LDFLAGS = -Wl,--as-needed -L/usr/lib64 -L/usr/lib -L/usr/lib64 -Wl,--as-needed -Wl,-rpath,'/usr/pgsql-16/lib',--enable-new-dtags LDFLAGS_EX = LDFLAGS_SL = LIBS = -lpgcommon -lpgport -lselinux -lzstd -llz4 -lxslt -lxml2 -lpam -lssl -lcrypto -lgssa

Re: segmentation fault

"Zechman, Derek S" writes: > We are getting a segmentation fault which seems to be specific to pg16 on > redhat 8. Tested on pg14 and pg15 with no problems. Also tested with pg16 > on redhat 9 - no issues. The developer determined that it is specific to > select into a defined variable withi

Re: Segmentation fault on RelationGetDescr in my first extension

At Thu, 29 Dec 2022 13:52:18 +0300, Дмитрий Цветков wrote in > I'm trying to write my first extension and open a table in it. > I use check_password_hook and my function executes at the moment of > changing user password. > > But if I try to open a table inside this function, I get Segmentation

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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,

Re: Segmentation Fault PG 14

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`

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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 +-+---

Re: Segmentation Fault PG 14

All the extensions installed in this database are these: ``` List of installed extensions Name| Version | Schema | Description +-++--- amcheck

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation Fault PG 14

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

Re: Segmentation fault in volatile c function

Thank you! I used that. The segmentation fault came from a later code in my hook. But that helped. > On Oct 27, 2021, at 12:47 PM, Peter Geoghegan wrote: > > On Wed, Oct 27, 2021 at 12:39 PM Louise Grandjonc > wrote: >> I'm creating my first ever extension. The function that I'm trying to writ

Re: Segmentation fault in volatile c function

On Wed, Oct 27, 2021 at 12:39 PM Louise Grandjonc wrote: > I'm creating my first ever extension. The function that I'm trying to write > takes the schema and name of a table, and adds it in a table with all the > tables the extension follows. > In that table I want the schema, name and oid of th

Re: Segmentation fault on startup

Hi, a little follow-up to this case... since redis didn't work correctly, too, I looked around for a solution for that, too. It seems that the alpine image 3.13 for arm7 is broken at the moment... see the answer here: https://stackoverflow.com/questions/66091978/corrupt-date-with-redis6-alp

Re: Segmentation fault on startup

(again to the list...) Am 01.02.21 um 21:40 schrieb Tom Lane: Helmut Bender writes: I'm running a nextcloud server in a docker container on an RasPi 4 (only SSD, no SD), which uses PostgreSQL 10 as server. 10.what? We're already up to 15 patch releases for that branch. As I use the docker

Re: Segmentation fault on startup

Helmut Bender writes: > I'm running a nextcloud server in a docker container on an RasPi 4 (only > SSD, no SD), which uses PostgreSQL 10 as server. 10.what? We're already up to 15 patch releases for that branch. > Today I had to restart the RasPi. Now the container fails to start with > a seg

Re: Segmentation fault with PG-12

På torsdag 10. oktober 2019 kl. 22:21:13, skrev Andres Freund < and...@anarazel.de >: On 2019-10-10 15:32:38 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-10-09 10:16:37 -0400, Tom Lane wrote: > >> Well, it shows that the failure is occurring while tryi

Re: Segmentation fault with PG-12

On 2019-10-10 15:32:38 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-10-09 10:16:37 -0400, Tom Lane wrote: > >> Well, it shows that the failure is occurring while trying to evaluate > >> a variable in a trigger's WHEN clause during > >> "UPDATE origo_email_delivery SET folder_id=$1, c

Re: Segmentation fault with PG-12

På torsdag 10. oktober 2019 kl. 21:32:38, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andres Freund writes: > On 2019-10-09 10:16:37 -0400, Tom Lane wrote: >> Well, it shows that the failure is occurring while trying to evaluate >> a variable in a trigger's WHEN clause during >> "UPDATE orig

Re: Segmentation fault with PG-12

Andres Freund writes: > On 2019-10-09 10:16:37 -0400, Tom Lane wrote: >> Well, it shows that the failure is occurring while trying to evaluate >> a variable in a trigger's WHEN clause during >> "UPDATE origo_email_delivery SET folder_id=$1, created=$2\nWHERE entity_id >> IN ($3)\nRETURNING entity

Re: Segmentation fault with PG-12

We had another crash today, and it appears to be the same: #0 slot_deform_heap_tuple (natts=26, offp=0x5598eba0b968, tuple=, slot=0x5598eba0b920) at ./build/../src/backend/executor/execTuples.c:895 -- Andreas Joseph Krogh

Re: Segmentation fault with PG-12

On 2019-10-10 09:05:06 +0200, Andreas Joseph Krogh wrote: > (Tom: This mail is only viewable as text/html, to if you're reading the > text/plain version it will seem "hashed") I'm totally not ok with that btw.

Re: Segmentation fault with PG-12

På torsdag 10. oktober 2019 kl. 07:25:26, skrev Andres Freund < and...@anarazel.de >: On 2019-10-09 10:16:37 -0400, Tom Lane wrote: > Andreas Joseph Krogh writes: > > Attached is output from "bt full". Is this helpful? > > Well, it shows that the failure is occurrin

Re: Segmentation fault with PG-12

On 2019-10-09 10:16:37 -0400, Tom Lane wrote: > Andreas Joseph Krogh writes: > > Attached is output from "bt full". Is this helpful? > > Well, it shows that the failure is occurring while trying to evaluate > a variable in a trigger's WHEN clause during > "UPDATE origo_email_delivery SET folder_

Re: Segmentation fault with PG-12

Andreas Joseph Krogh writes: > Is it OK if I send you the table/trigger-definitions off-list? Sure, but please share with Andres [cc'ed] as well. regards, tom lane

Re: Segmentation fault with PG-12

På onsdag 09. oktober 2019 kl. 16:16:37, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > Attached is output from "bt full". Is this helpful? Well, it shows that the failure is occurring while trying to evaluate a variable in a trigger's WHEN clause during "UPDATE or

Re: Segmentation fault with PG-12

Andreas Joseph Krogh writes: > Attached is output from "bt full". Is this helpful? Well, it shows that the failure is occurring while trying to evaluate a variable in a trigger's WHEN clause during "UPDATE origo_email_delivery SET folder_id=$1, created=$2\nWHERE entity_id IN ($3)\nRETURNING ent

Re: Segmentation fault with PG-12

På tirsdag 08. oktober 2019 kl. 17:24:21, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > Will running a debug-enabled build slow things noticably down? gcc promises that the generated code is the same with or without debug. I think clang does too. With other compile

Re: Segmentation fault with PG-12

På tirsdag 08. oktober 2019 kl. 17:24:21, skrev Tom Lane mailto:t...@sss.pgh.pa.us>>: Andreas Joseph Krogh writes: > Will running a debug-enabled build slow things noticably down? gcc promises that the generated code is the same with or without debug. I think clang does too. With other compile

Re: Segmentation fault with PG-12

Andreas Joseph Krogh writes: > Will running a debug-enabled build slow things noticably down? gcc promises that the generated code is the same with or without debug. I think clang does too. With other compilers you may pay some penalty. > Is there a way > to make it dump a stack-trace (or back

Re: Segmentation fault with core dump

Glauco Torres writes: > Today I left to generate more core-dump, follow the return, > (gdb) bt > #0 tbm_comparator (left=left@entry=0x1d5ca08, right=right@entry=0x3acdb70) > at tidbitmap.c:1031 > #1 0x00801268 in med3 (a=0x1d5ca08 "\350>\337\001", b=0x3acdb70 > , c=0x583ecd8 bounds>, c

Re: Segmentation fault with core dump

> > Might be worth comparing sha1sum's of the postgres executable between > this server and one that's not having the problem, just to eliminate > the corrupted-binary theory. > > > The return is the same for the two servers, $ sha1sum /usr/pgsql-9.6/bin/postmaster 56bcb4d644a8b00f07e9bd42f9a3f02

Re: Segmentation fault with core dump

Glauco Torres writes: >> The system is a CentOS 7, and PG was installed using PGDG's YUM repository. Might be worth comparing sha1sum's of the postgres executable between this server and one that's not having the problem, just to eliminate the corrupted-binary theory. reg

Re: Segmentation fault with core dump

> > That would result in nonsensical gdb output, most likely; but Glauco's > trace is internally consistent enough that I doubt gdb is lying to us. > In any case, the crash is an observable fact :-( > > > The system is a CentOS 7, and PG was installed using PGDG's YUM repository. We are pretty sur

Re: Segmentation fault with core dump

Merlin Moncure wrote: > simple > SELECT version(); > ...can give a lot of hints on who/what compiled the database if you don't > know. Probably, this is why Glauco included the output in his opening letter. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 2

Re: Segmentation fault with core dump

Alvaro Herrera writes: > Tom Lane wrote: >> Hm. I'm not normally one to jump to the conclusion that something is a >> compiler bug, but it's hard to explain this stack trace any other way. >> The value of "n" passed to the inner invocation of pg_qsort should not >> have been more than 29914, but

Re: Segmentation fault with core dump

Tom Lane wrote: > Glauco Torres writes: > > (gdb) bt > > #0 ckpt_buforder_comparator (pa=pa@entry=0x7f6fa9ef4b2c, > > pb=pb@entry=0x1be06d2d06644) > > at bufmgr.c:4137 > > #1 0x00801268 in med3 (a=0x7f6fa9ef4b2c "\177\006", > > b=0x1be06d2d06644 , > > c=0x2fc9dfbb1815c , cmp=0x6a4d20 > >

Re: Segmentation fault with core dump

On Wed, Jan 10, 2018 at 11:08 AM, Tom Lane wrote: > Glauco Torres writes: >> (gdb) bt >> #0 ckpt_buforder_comparator (pa=pa@entry=0x7f6fa9ef4b2c, >> pb=pb@entry=0x1be06d2d06644) >> at bufmgr.c:4137 >> #1 0x00801268 in med3 (a=0x7f6fa9ef4b2c "\177\006", >> b=0x1be06d2d06644 , >> c=0x2fc9

Re: Segmentation fault with core dump

Glauco Torres writes: > (gdb) bt > #0 ckpt_buforder_comparator (pa=pa@entry=0x7f6fa9ef4b2c, > pb=pb@entry=0x1be06d2d06644) > at bufmgr.c:4137 > #1 0x00801268 in med3 (a=0x7f6fa9ef4b2c "\177\006", > b=0x1be06d2d06644 , > c=0x2fc9dfbb1815c , cmp=0x6a4d20 > ) > at qsort.c:107 > #2 0x00