RE: segmentation fault

pg_show_plan is in the shared_preload_libraries then we get a segmentation fault. I checked the github repo from cybertec and surprised there have been no reported issues with it. I will be posting there shortly. BINDIR = /usr/pgsql-16/bin DOCDIR = /usr/pgsql-16/doc HTMLDIR = /usr/pgsql-16

segmentation fault

Hello All, 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 within a function. We have

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 i

Re: signal 11: Segmentation fault ; query constraint list; pg16.3

t; > when connect to database postgres this query is OK, but run on user > database, got segmentation fault. > > I tried your query on 16.1 and I'm unable to reproduce the crash. > > Are you able to recreate this on a freshly installed instance after > creating the table in q

Re: signal 11: Segmentation fault ; query constraint list; pg16.3

On Mon, 20 May 2024 at 22:32, milist ujang wrote: > > postgres 16.1; rocky 9.3 > > when connect to database postgres this query is OK, but run on user database, > got segmentation fault. I tried your query on 16.1 and I'm unable to reproduce the crash. Are you able t

signal 11: Segmentation fault ; query constraint list; pg16.3

postgres 16.1; rocky 9.3 when connect to database postgres this query is OK, but run on user database, got segmentation fault. 2024-05-20 17:16:54.942 WIB,,,134291,,6648420a.20c93,165,,2024-05-18 12:52:10 WIB,,0,LOG,0,"server process (PID 487952) was terminated by signal 11: Segment

Re: Ynt: Pgbackrest Restore Error - Segmentation fault (core dumped)

On 9/6/23 11:27, pgdba pgdba wrote: I removed  it but I keep getting the same error OK.  The custom here is to put your response at the bottom  of short messages ("bottom post") or intermixed with original as appropriate on

Ynt: Pgbackrest Restore Error - Segmentation fault (core dumped)

I removed it but I keep getting the same error Gönderen: Rob Sargent Gönderildi: 6 Eylül 2023 Çarşamba 16:32 Kime: pgsql-general@lists.postgresql.org Konu: Re: Pgbackrest Restore Error - Segmentation fault (core dumped) On 9/6/23 05:08, pgdba pgdba wrote: Hello

Re: Pgbackrest Restore Error - Segmentation fault (core dumped)

es --stanza=db3 --type=immediate Segmentation fault (core dumped) Thanks, Have you tried removing the invalid option ('archive-mode') from the config file?

Re: Pgbackrest Restore Error - Segmentation fault (core dumped)

> On 6 Sep 2023, at 13:08, pgdba pgdba wrote: > > Hello, when I restore with Pgbackrest, I get the following error, I couldn't > find a solution when I researched, can you support? You might be better off raising this question on the pgbackreset Github repo as an issue, where more pgbackrest de

Pgbackrest Restore Error - Segmentation fault (core dumped)

file contains invalid option 'archive-mode' 2023-09-06 06:54:45.826 P00 INFO: restore command begin 2.27: --config=/etc/pgbackrest/pgbackrest.conf --log-level-console=info --pg1-path=/var/lib/ postgresql/11 --repo1-host=0.0.0.1 --repo1-host-user=postgres --stanza=db3 --type=immediate Seg

Re: Segmentation fault on RelationGetDescr in my first extension

this function, I get Segmentation fault > on the line with "RelationGetDescr". > What am I doing wrong? table_open() should error out when it is going to return an invalid Relation*, and RelationGetDescr(rel) is "rel->rd_att". So the RelationGetDescr() cannot get a segv even i

Fwd: Segmentation fault on RelationGetDescr in my first extension

Hi! 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 fault on the line with "RelationGetDescr". What a

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

L/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). > > > &g

Re: Segmentation Fault PG 14

x27;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

Re: Segmentation Fault PG 14

| 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

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

Segmentation Fault PG 14

lel worker" (PID 9558) was terminated by signal 11: Segmentation fault 2022-11-07 17:23:19.423 UTC [728] DETAIL: Failed process was running: select blablabla from heavyquery where ...; 2022-11-07 17:23:19.423 UTC [728] LOG: terminating any other active server processes 2022-11-07 17:23:1

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On 11/7/22 09:43, Tom Lane wrote: Ron writes: On 11/7/22 08:02, Tom Lane wrote: call. It'd still be recommendable to pg_dumpall and restore into a freshly-initdb'd cluster, because otherwise you can't be real sure that you identified and cleared all the data corruption. Why *just* pg_dumpall

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

Ron writes: > On 11/7/22 08:02, Tom Lane wrote: >> call. It'd still be recommendable to pg_dumpall and restore into >> a freshly-initdb'd cluster, because otherwise you can't be real >> sure that you identified and cleared all the data corruption. > Why *just* pg_dumpall instead of "pg_dumpall --

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On 11/7/22 08:02, Tom Lane wrote: [snip] call. It'd still be recommendable to pg_dumpall and restore into a freshly-initdb'd cluster, because otherwise you can't be real sure that you identified and cleared all the data corruption. Why *just* pg_dumpall instead of "pg_dumpall --globals-only" an

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On Mon, Nov 07, 2022 at 09:02:26AM -0500, Tom Lane wrote: > Stefan Froehlich writes: > > On Mon, Nov 07, 2022 at 08:17:10AM -0500, Mladen Gogala wrote: > >> On 11/7/22 06:19, Laurenz Albe wrote: > >>> Don't continue to work with that cluster even if everything seems OK now. > >>> "pg_dumpall" and

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

Stefan Froehlich writes: > On Mon, Nov 07, 2022 at 08:17:10AM -0500, Mladen Gogala wrote: >> On 11/7/22 06:19, Laurenz Albe wrote: >>> Don't continue to work with that cluster even if everything seems OK now. >>> "pg_dumpall" and restore to a new cluster on good hardware. >> Why would that be ne

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On Mon, Nov 07, 2022 at 08:17:10AM -0500, Mladen Gogala wrote: > On 11/7/22 06:19, Laurenz Albe wrote: > >Don't continue to work with that cluster even if everything seems OK now. > >"pg_dumpall" and restore to a new cluster on good hardware. > Why would that be necessary if the original machine

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On 11/7/22 06:19, Laurenz Albe wrote: Don't continue to work with that cluster even if everything seems OK now. "pg_dumpall" and restore to a new cluster on good hardware. Why would that be necessary if the original machine works well now? -- Mladen Gogala Database Consultant Tel: (347) 321-12

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On Mon, 2022-11-07 at 11:17 +0100, Stefan Froehlich wrote: > On Sun, Nov 06, 2022 at 09:48:32AM -0500, Tom Lane wrote: > > Stefan Froehlich writes: > > > > # create extension amcheck; > > > > # select oid, relname from pg_class where relname > > > > ='faultytablename_pkey'; > > > > [returns oid 5

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On Sun, Nov 06, 2022 at 09:48:32AM -0500, Tom Lane wrote: > Stefan Froehlich writes: > > | # create extension amcheck; > > | # select oid, relname from pg_class where relname ='faultytablename_pkey'; > > | [returns oid 537203] > > | # select bt_index_check(537203, true); > > | server closed the co

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

Stefan Froehlich writes: > I am using v13, but well: > | # create extension amcheck; > | # select oid, relname from pg_class where relname ='faultytablename_pkey'; > | [returns oid 537203] > | # select bt_index_check(537203, true); > | server closed the connection unexpectedly Oh ... up through

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

On Sun, Nov 06, 2022 at 09:13:08AM -0500, Tom Lane wrote: > > | 2022-11-06 11:52:36.367 CET [2098-35] LOG: server process (PID 2964738) > > was terminated by signal 11: Segmentation fault > contrib/amcheck might help to identify the faulty data (at this > point there's

Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault

ed by signal 11: Segmentation fault > Whatever was "done" does not prevent the problem from being > reproducible. I tried to track down this faulty record as well, but > binary proves difficult with 25*10^6 rows if the server crashes and > rebuilds after each try. > Is there

server process (PID 2964738) was terminated by signal 11: Segmentation fault

I get: | 2022-11-06 11:52:36.367 CET [2098-35] LOG: server process (PID 2964738) was terminated by signal 11: Segmentation fault | [...] | 2022-11-06 11:53:46.229 CET [2964744-2] LOG: database system was not properly shut down; automatic recovery in progress | 2022-11-06 11:53:46.263 CET [296

Re: gist segmentation fault

Thanks, Том Lane. We will wait for the release. Sent with ProtonMail secure email. --- Original Message --- On Monday, April 4th, 2022 at 17:12, Tom Lane wrote: > Arup Nanda arup.na...@protonmail.com writes: > > > We're preparing to upgrade postgresql from 12.8 to 14.2 but still we

Re: gist segmentation fault

Arup Nanda writes: > We're preparing to upgrade postgresql from 12.8 to 14.2 but still we have > some bugs and issues. Most of them are our fault, but now we have problem > wedon't know how to play with it. > [ crash in copy_ltree for an upgraded GIST index ] I think this is the same problem al

gist segmentation fault

t;,os.id) as "SubdivisionId" ,fros."UserId" ,fros."UserLogin" from "FullRightsOfStructure" as fros join dwh."OFAS_Org_Structure" as OS on os.id = fros."SubdivisionId" left join dwh."OFAS_Org_Structure"

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 func

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

Segmentation fault in volatile c function

iled. ``` In the logs, for the latest, I get ``` 2021-10-27 12:28:02.712 PDT [44115] LOG: statement: select mygreat.add_mygreat_table('public', 'sampledata3'); 2021-10-27 12:28:02.718 PDT [43936] LOG: server process (PID 44115) was terminated by signal 11: Segmentation fault

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

Segmentation fault on startup

6.010 UTC [31] LOG: 0: startup process (PID 32) was terminated by signal 11: Segmentation fault 1970-05-04 03:17:36.010 UTC [31] LOCATION: LogChildExit, postmaster.c:3639 1970-05-04 03:17:36.010 UTC [31] LOG: 0: aborting startup due to startup process failure 1970-05-04 03:17:36.010 UTC [

Re: How to debug "background worker "parallel worker" (PID 32152) was terminated by signal 11: Segmentation fault"

On Mon, 27 Apr 2020 at 17:52, Tom Lane wrote: > > Radu Radutiu writes: > > Can you guide me how to debug postgresql crash? > > A stack trace would be pretty useful. > > https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend > > regards, tom lane

Re: How to debug "background worker "parallel worker" (PID 32152) was terminated by signal 11: Segmentation fault"

Radu Radutiu writes: > Can you guide me how to debug postgresql crash? A stack trace would be pretty useful. https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend regards, tom lane

How to debug "background worker "parallel worker" (PID 32152) was terminated by signal 11: Segmentation fault"

partition tables crashed the postgresql instance. I have in the log: 2020-04-26 17:35:50.065 EEST [8385] LOG: background worker "parallel worker" (PID 32152) was terminated by signal 11: Segmentation fault 2020-04-26 17:35:50.065 EEST [8385] DETAIL: Failed process was running: CREATE INDEX I

Re: terminated by signal 11: Segmentation fault

Hi Tom, Thank you, we have that same scenario. Regards Gerrit On Wed, 13 Nov 2019, 20:57 Tom Lane, wrote: > Gerrit Fouche writes: > > This is the second time I get this error since Postgresql 12 was > officially > > released. My version: > > PostgreSQL 12.0 (Ubuntu 12.0-2.pgdg18.04+1) on x86_64

Re: terminated by signal 11: Segmentation fault

Gerrit Fouche writes: > This is the second time I get this error since Postgresql 12 was officially > released. My version: > PostgreSQL 12.0 (Ubuntu 12.0-2.pgdg18.04+1) on x86_64-pc-linux-gnu, > compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0, 64-bit Given that this failed in an UPDATE, I

terminated by signal 11: Segmentation fault

in the right direction to solve it? 2019-11-13 11:18:31.296 SAST,,,5033,,5dc7a74d.13a9,75,,2019-11-10 07:59:41 SAST,,0,LOG,0,"server process (PID 17257) was terminated by signal 11: Segmentation fault","Failed process was running: UPDATE stock_items SET ""

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

Segmentation fault with PG-12

In our production-environment we get sig11 every now and then after upgrading to PG-12: 2019-10-08 15:45:29.654 CEST [8829-76] LOG: server process (PID 20631) was terminated bysignal 11: Segmentation fault 2019-10-08 15:45:29.654 CEST [8829-77] DETAIL: Failed process was running: COMMIT 2019

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Thomas Munro writes: > On Thu, Mar 21, 2019 at 5:07 PM Tom Lane wrote: >> Thomas Munro writes: >>> If someone out there is not enabling any of that stuff >>> because their system doesn't like threads, they can use >>> --disable-thread-safety to avoid the effects of this change. >> No, that's no

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Thu, Mar 21, 2019 at 5:07 PM Tom Lane wrote: > Thomas Munro writes: > > If someone out there is not enabling any of that stuff > > because their system doesn't like threads, they can use > > --disable-thread-safety to avoid the effects of this change. > > No, that's nonsense; --disable-thread-

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Thomas Munro writes: > On Wed, Mar 20, 2019 at 10:51 AM Tom Lane wrote: >> It's reasonable to assume that the proposed patch won't cause real issues >> on any modern platform, but I'm not sure we can assume that for old ones, >> so the whole thing is making me a bit nervous. > Sure, it's possibl

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Wed, Mar 20, 2019 at 10:51 AM Tom Lane wrote: > Thomas Munro writes: > > Even though I can't reproduce the problem myself, I'm quite keen to go > > ahead and push the patch I proposed for v12 anyway, and close this > > case. Otherwise this problem could just keep coming back until > > libldap

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Thomas Munro writes: > Even though I can't reproduce the problem myself, I'm quite keen to go > ahead and push the patch I proposed for v12 anyway, and close this > case. Otherwise this problem could just keep coming back until > libldap.so is eventually entirely phased out by all distros. In 20

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Fri, Mar 15, 2019 at 4:46 PM Noah Misch wrote: > Thanks. That rules out my guess. I don't have another guess at this time. Even though I can't reproduce the problem myself, I'm quite keen to go ahead and push the patch I proposed for v12 anyway, and close this case. Otherwise this problem c

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Fri, Mar 15, 2019 at 12:10:59AM +0800, Mike Yeap wrote: > Hi Noah, below is the output from one of the servers having this issue: > > $ echo "select pg_backend_pid(); load 'dblink'; select pg_sleep(100)" | psql > -X & > [1] 9731 > > $ select pg_backend_pid(); load 'dblink'; select pg_sleep(10

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Hi Noah, below is the output from one of the servers having this issue: $ echo "select pg_backend_pid(); load 'dblink'; select pg_sleep(100)" | psql -X & [1] 9731 $ select pg_backend_pid(); load 'dblink'; select pg_sleep(100) pg_backend_pid 9732 (1 row) LOAD $ gdb -

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Thu, Mar 14, 2019 at 05:18:49PM +1300, Thomas Munro wrote: > On Thu, Mar 7, 2019 at 4:19 PM Noah Misch wrote: > > Has anyone else reproduced this? > > I tried, but could not reproduce this problem on "CentOS Linux release > 7.6.1810 (Core)" using OpenLDAP "2.4.44-21.el7_6" (same as Mike > repo

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Thu, Mar 7, 2019 at 4:19 PM Noah Misch wrote: > Has anyone else reproduced this? I tried, but could not reproduce this problem on "CentOS Linux release 7.6.1810 (Core)" using OpenLDAP "2.4.44-21.el7_6" (same as Mike reported, what yum install is currently serving up). I tried "make check" in

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Thu, Mar 07, 2019 at 10:45:56AM +1300, Thomas Munro wrote: > On Wed, Feb 27, 2019 at 11:28 AM Tom Lane wrote: > > Thomas Munro writes: > > > I don't see pthread_is_threaded_np() on any non-Apple systems in my > > > lab. > > > > Yeah, I thought that might be a Mac thing. I wonder if POSIX has

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Adding Noah to thread. On Wed, Feb 27, 2019 at 11:28 AM Tom Lane wrote: > Thomas Munro writes: > > I don't see pthread_is_threaded_np() on any non-Apple systems in my > > lab. > > Yeah, I thought that might be a Mac thing. I wonder if POSIX has any > usable equivalent. I don't see anything lik

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Thomas Munro writes: > On Wed, Feb 27, 2019 at 3:57 AM Tom Lane wrote: >> If pthread_is_threaded_np(), or something equivalent, is widely available >> then it might be all right to try solving this going forward by switching >> to libldap_r and seeing if anyone hits those cross-checks. I'd be af

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Wed, Feb 27, 2019 at 3:57 AM Tom Lane wrote: > Thomas Munro writes: > > Question > > for the list: other stuff in the server needs libpthread (SSL, LLVM, > > ...), so why are we insisting on using non-MT LDAP? > > The traditional reason for avoiding that is the risk of a server > process becom

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Thomas Munro writes: > Question > for the list: other stuff in the server needs libpthread (SSL, LLVM, > ...), so why are we insisting on using non-MT LDAP? The traditional reason for avoiding that is the risk of a server process becoming multi-threaded. There are live bugs of that ilk on Darwin

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Greetings Mike, * Mike Yeap (wkk1...@gmail.com) wrote: > Hi Thomas, I see. guess I can't use LDAP authentication for now, :-( If you're in an active directory environment, you should really be using Kerberos for authentication and NOT LDAP anyway. LDAP-based authentication involves sending t

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Tue, Feb 26, 2019 at 9:11 PM Thomas Munro wrote: > On Tue, Feb 26, 2019 at 8:17 PM Mike Yeap wrote: > > Hi Thomas, does that mean the bug is still there? > I haven't tried to repro this myself, but it certainly sounds like it. > It also sounds like it would probably go away if you switched to

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Hi Thomas, I see. guess I can't use LDAP authentication for now, :-( Hopefully this problem is solved in future version, thank you! Regards, Mike Yeap On Tue, Feb 26, 2019 at 4:12 PM Thomas Munro wrote: > On Tue, Feb 26, 2019 at 8:17 PM Mike Yeap wrote: > > Hi Thomas, does that mean the b

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Tue, Feb 26, 2019 at 8:17 PM Mike Yeap wrote: > Hi Thomas, does that mean the bug is still there? Hi Mike, I haven't tried to repro this myself, but it certainly sounds like it. It also sounds like it would probably go away if you switched to a Debian-derived distro, instead of a Red Hat-deri

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Hi Thomas, does that mean the bug is still there? Regards, Mike Yeap On Mon, Feb 25, 2019 at 4:06 PM Thomas Munro wrote: > On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap wrote: > > openldap-clients.x86_64 2.4.44-21.el7_6 > @updates > > openldap-devel.i686

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

On Thu, Feb 21, 2019 at 2:42 PM Mike Yeap wrote: > openldap-clients.x86_64 2.4.44-21.el7_6 > @updates > openldap-devel.i686 2.4.44-21.el7_6updates > openldap-devel.x86_64 2.4.44-21.el7_6updates >

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Hi Tom, when I run "ldd /usr/pgsql-10/bin/postmaster" I got this output: # ldd /usr/pgsql-10/bin/postmaster linux-vdso.so.1 => (0x7ffd4ec65000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7eff8b5d3000) libxml2.so.2 => /lib64/libxml2.so.2 (0x7eff8b268000) libpam.so.0 => /lib64/libpam.

Re: LDAP authenticated session terminated by signal 11: Segmentation fault, PostgresSQL server terminates other active server processes

Mike Yeap writes: >> Are the "postgres" executable and libpq linked with the same version of >> OpenLDAP? > How should I check whether they are linked? "ldd" should show the dependencies of whatever executable or library you point it at. regards, tom lane

  1   2   >