Thread: PostgreSQL 12 crash with segmentation violation

PostgreSQL 12 crash with segmentation violation

From

Marcel Ruff

Date:

04 November 2019, 10:29:47

Hi,

I'm using posgreSQL for many years, all versions like 9x, 10x, 11x - thank you very much for this excellent piece of software.

Now I have upgraded to postgresql 12 and get a crash about once per day, unfortunately our midleware (Java via current JDBC) stops immediately on this and all users are offline.

In pg_log/postgresql-2019-10-31.csv I find entries like:

2019-10-31 07:03:03.750 CET,,,1516,,5db5cfa5.5ec,19,,2019-10-27 18:11:01 CET,,0,LOG,00000,"server process (PID 27439) was terminated by signal 11: Speicherzugriffsfehler","Failed proc
ess was running: update Location set enmea=$1, guid=$2, latDeci=$3, lonDeci=$4, modifiedByLoginName=$5, poiObjectId=$6, timestamp=$7, TRACK_ID=$8 where LOCATION_ID=$9",,,,,,,,""

I have built postgresql from source on a current Debian Linux with

./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-pam --with-openssl --with-libxml –with-libxslt –with-llvm

td p { background: transparent none repeat scroll 0% 0%; }p { margin-bottom: 0.25cm; line-height: 120%; background: transparent none repeat scroll 0% 0%; }code.western { font-family: "Liberation Mono", monospace; }code.cjk { font-family: "Droid Sans Fallback", monospace; }code.ctl { font-family: "Liberation Mono", monospace; }a:link { color: rgb(0, 0, 128); text-decoration: underline; }a:visited { color: rgb(128, 0, 0); text-decoration: underline; }

Additionally postgis is compiled into and a little own c library (language C strict) is used.

I have already disabled llvm with jit = off which didn't help.

How can I track down the problem?

thank you
Marcel

Re: PostgreSQL 12 crash with segmentation violation

From

Alvaro Herrera

Date:

04 November 2019, 15:37:53

On 2019-Nov-04, Marcel Ruff wrote:

> Now I have upgraded to postgresql 12 and get a crash about once per day,
> unfortunately our midleware (Java via current JDBC) stops immediately on
> this and all users are offline.
> 
> In  pg_log/postgresql-2019-10-31.csv I find entries like:
> 
> 2019-10-31 07:03:03.750 CET,,,1516,,5db5cfa5.5ec,19,,2019-10-27 18:11:01
> CET,,0,LOG,00000,"server process (PID 27439) was terminated by signal
> 11: Speicherzugriffsfehler","Failed proc
> ess was running: update Location set enmea=$1, guid=$2, latDeci=$3,
> lonDeci=$4, modifiedByLoginName=$5, poiObjectId=$6, timestamp=$7,
> TRACK_ID=$8 where LOCATION_ID=$9",,,,,,,,""

> How can I track down the problem?

The first you need to do is obtain a crash dump.  This page may help:


https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_reproducibly_crashing_backend

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: PostgreSQL 12 crash with segmentation violation

From

Tom Lane

Date:

04 November 2019, 17:24:48

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Nov-04, Marcel Ruff wrote:
>> Now I have upgraded to postgresql 12 and get a crash about once per day,
>> ...
>> How can I track down the problem?

> The first you need to do is obtain a crash dump.  This page may help:

>
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_reproducibly_crashing_backend

Also, as long as you're building from source anyway, you might pull down
v12 branch tip from our git repo, or use a nightly snapshot tarball [1]
to see if the problem's already fixed.

            regards, tom lane

[1] https://www.postgresql.org/ftp/snapshot/12/

Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

From

Marcel Ruff

Date:

06 November 2019, 09:48:02

Hi,

here is the crash dump, it is the current postgresql 12 release (not yet a current git clone) on Debian Linux with 40G RAM and AMD Opteron 23xx (Gen 3 Class Opteron)

    ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-pam --with-openssl --with-libxml –with-libxslt –with-llvm --enable-debug
    make -j 8
    make install
    cd contrib
    make -j 8
    make install

and the default postgresql.conf but with jit = false (it also happens with jit = on):

--------------
[New LWP 21468]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: watchee watchee 127.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at ../../../../src/include/utils/memutils.h:127
127             context = *(MemoryContext *) (((char *) pointer) - sizeof(void *));
(gdb) where
#0 0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at ../../../../src/include/utils/memutils.h:127
#1 pfree (pointer=0x0) at mcxt.c:1033
#2 0x000055ceb90fcfe5 in heap_freetuple (htup=<optimized out>) at heaptuple.c:1340
#3 0x000055ceb92931a1 in tts_buffer_heap_clear (slot=0x55ceba097a18) at execTuples.c:652
#4 0x000055ceb9293b05 in ExecClearTuple (slot=0x55ceba097a18) at ../../../src/include/executor/tuptable.h:428
#5 ExecForceStoreHeapTuple (tuple=0x55ceb9aad760, slot=0x55ceba097a18, shouldFree=<optimized out>) at execTuples.c:1446
#6 0x000055ceb926b851 in ExecBRUpdateTriggers (estate=estate@entry=0x55ceb9a4e090, epqstate=epqstate@entry=0x55ceb9a4ed28, relinfo=relinfo@entry=0x55ceb9a4e300,
    tupleid=tupleid@entry=0x7fff3cbcb92a, fdw_trigtuple=fdw_trigtuple@entry=0x0, newslot=newslot@entry=0x55ceba097a18) at trigger.c:3109
#7 0x000055ceb92ac464 in ExecUpdate (mtstate=mtstate@entry=0x55ceb9a4ec30, tupleid=0x7fff3cbcb92a, oldtuple=0x0, slot=0x55ceba097a18, planSlot=0x55ceba0978b8,
    epqstate=epqstate@entry=0x55ceb9a4ed28, estate=0x55ceb9a4e090, canSetTag=true) at nodeModifyTable.c:1072
#8 0x000055ceb92ad862 in ExecModifyTable (pstate=0x55ceb9a4ec30) at nodeModifyTable.c:2223
#9 0x000055ceb928860b in ExecProcNode (node=0x55ceb9a4ec30) at ../../../src/include/executor/executor.h:239
#10 ExecutePlan (execute_once=<optimized out>, dest=0x55ceb977fb60 <donothingDR>, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_UPDATE,
    use_parallel_mode=<optimized out>, planstate=0x55ceb9a4ec30, estate=0x55ceb9a4e090) at execMain.c:1646
#11 standard_ExecutorRun (queryDesc=0x55ceba065378, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:364
#12 0x000055ceb93d9140 in ProcessQuery (plan=<optimized out>,
    sourceText=0x55ceba065140 "update Location set enmea=$1, guid=$2, latDeci=$3, lonDeci=$4, modifiedByLoginName=$5, poiObjectId=$6, timestamp=$7, TRACK_ID=$8 where LOCATION_ID=$9", params=0x55ceba065268, queryEnv=0x0, dest=0x55ceb977fb60 <donothingDR>, completionTag=0x7fff3cbcbdd0 "") at pquery.c:161
#13 0x000055ceb93d9370 in PortalRunMulti (portal=portal@entry=0x55ceb9a31750, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false,
    dest=0x55ceb977fb60 <donothingDR>, dest@entry=0x55ceb99cd950, altdest=0x55ceb977fb60 <donothingDR>, altdest@entry=0x55ceb99cd950,
    completionTag=completionTag@entry=0x7fff3cbcbdd0 "") at pquery.c:1283
#14 0x000055ceb93d9e51 in PortalRun (portal=portal@entry=0x55ceb9a31750, count=count@entry=1, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=false,
    dest=dest@entry=0x55ceb99cd950, altdest=altdest@entry=0x55ceb99cd950, completionTag=0x7fff3cbcbdd0 "") at pquery.c:796
#15 0x000055ceb93d7557 in exec_execute_message (max_rows=1, portal_name=0x55ceb99cd540 "") at postgres.c:2090
#16 PostgresMain (argc=<optimized out>, argv=argv@entry=0x55ceb99f5958, dbname=<optimized out>, username=<optimized out>) at postgres.c:4297
--Type <RET> for more, q to quit, c to continue without paging--
#17 0x000055ceb9363ce2 in BackendRun (port=0x55ceb99f1920, port=0x55ceb99f1920) at postmaster.c:4431
#18 BackendStartup (port=0x55ceb99f1920) at postmaster.c:4122
#19 ServerLoop () at postmaster.c:1704
#20 0x000055ceb9364c10 in PostmasterMain (argc=1, argv=0x55ceb99c7270) at postmaster.c:1377
#21 0x000055ceb90f3886 in main (argc=1, argv=0x55ceb99c7270) at main.c:228

Thank you
Marcel

Am 04.11.19 um 15:24 schrieb Tom Lane:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

On 2019-Nov-04, Marcel Ruff wrote:

Now I have upgraded to postgresql 12 and get a crash about once per day,
...
How can I track down the problem?

The first you need to do is obtain a crash dump.  This page may help:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_reproducibly_crashing_backend

Also, as long as you're building from source anyway, you might pull down
v12 branch tip from our git repo, or use a nightly snapshot tarball [1]
to see if the problem's already fixed.
		regards, tom lane

[1] https://www.postgresql.org/ftp/snapshot/12/

--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com

Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

From

Marcel Ruff

Date:

10 November 2019, 18:55:14

Hi,

I have compiled

git clone git://git.postgresql.org/git/postgresql.git

to find out if this is more stable.

But pg_ctl start says:

"The data directory was initialized by PostgreSQL version 12, which is not compatible with this version 13devel"

I can't follow this way, as it is a production system with several hours of down time when doing pg_dump etc.

Marcel

Am 06.11.19 um 07:48 schrieb Marcel Ruff:

Hi,
here is the crash dump, it is the current postgresql 12 release (not yet a current git clone) on Debian Linux with 40G RAM and AMD Opteron 23xx (Gen 3 Class Opteron)
    ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-pam --with-openssl --with-libxml –with-libxslt –with-llvm --enable-debug
    make -j 8
    make install
    cd contrib
    make -j 8
    make install
and the default postgresql.conf but with jit = false (it also happens with jit = on):
--------------
[New LWP 21468]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: watchee watchee 127.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at ../../../../src/include/utils/memutils.h:127
127             context = *(MemoryContext *) (((char *) pointer) - sizeof(void *));
(gdb) where
#0 0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at ../../../../src/include/utils/memutils.h:127
#1 pfree (pointer=0x0) at mcxt.c:1033
#2 0x000055ceb90fcfe5 in heap_freetuple (htup=<optimized out>) at heaptuple.c:1340
#3 0x000055ceb92931a1 in tts_buffer_heap_clear (slot=0x55ceba097a18) at execTuples.c:652
#4 0x000055ceb9293b05 in ExecClearTuple (slot=0x55ceba097a18) at ../../../src/include/executor/tuptable.h:428
#5 ExecForceStoreHeapTuple (tuple=0x55ceb9aad760, slot=0x55ceba097a18, shouldFree=<optimized out>) at execTuples.c:1446
#6 0x000055ceb926b851 in ExecBRUpdateTriggers (estate=estate@entry=0x55ceb9a4e090, epqstate=epqstate@entry=0x55ceb9a4ed28, relinfo=relinfo@entry=0x55ceb9a4e300,
    tupleid=tupleid@entry=0x7fff3cbcb92a, fdw_trigtuple=fdw_trigtuple@entry=0x0, newslot=newslot@entry=0x55ceba097a18) at trigger.c:3109
#7 0x000055ceb92ac464 in ExecUpdate (mtstate=mtstate@entry=0x55ceb9a4ec30, tupleid=0x7fff3cbcb92a, oldtuple=0x0, slot=0x55ceba097a18, planSlot=0x55ceba0978b8,
    epqstate=epqstate@entry=0x55ceb9a4ed28, estate=0x55ceb9a4e090, canSetTag=true) at nodeModifyTable.c:1072
#8 0x000055ceb92ad862 in ExecModifyTable (pstate=0x55ceb9a4ec30) at nodeModifyTable.c:2223
#9 0x000055ceb928860b in ExecProcNode (node=0x55ceb9a4ec30) at ../../../src/include/executor/executor.h:239
#10 ExecutePlan (execute_once=<optimized out>, dest=0x55ceb977fb60 <donothingDR>, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_UPDATE,
    use_parallel_mode=<optimized out>, planstate=0x55ceb9a4ec30, estate=0x55ceb9a4e090) at execMain.c:1646
#11 standard_ExecutorRun (queryDesc=0x55ceba065378, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:364
#12 0x000055ceb93d9140 in ProcessQuery (plan=<optimized out>,
    sourceText=0x55ceba065140 "update Location set enmea=$1, guid=$2, latDeci=$3, lonDeci=$4, modifiedByLoginName=$5, poiObjectId=$6, timestamp=$7, TRACK_ID=$8 where LOCATION_ID=$9", params=0x55ceba065268, queryEnv=0x0, dest=0x55ceb977fb60 <donothingDR>, completionTag=0x7fff3cbcbdd0 "") at pquery.c:161
#13 0x000055ceb93d9370 in PortalRunMulti (portal=portal@entry=0x55ceb9a31750, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false,
    dest=0x55ceb977fb60 <donothingDR>, dest@entry=0x55ceb99cd950, altdest=0x55ceb977fb60 <donothingDR>, altdest@entry=0x55ceb99cd950,
    completionTag=completionTag@entry=0x7fff3cbcbdd0 "") at pquery.c:1283
#14 0x000055ceb93d9e51 in PortalRun (portal=portal@entry=0x55ceb9a31750, count=count@entry=1, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=false,
    dest=dest@entry=0x55ceb99cd950, altdest=altdest@entry=0x55ceb99cd950, completionTag=0x7fff3cbcbdd0 "") at pquery.c:796
#15 0x000055ceb93d7557 in exec_execute_message (max_rows=1, portal_name=0x55ceb99cd540 "") at postgres.c:2090
#16 PostgresMain (argc=<optimized out>, argv=argv@entry=0x55ceb99f5958, dbname=<optimized out>, username=<optimized out>) at postgres.c:4297
--Type <RET> for more, q to quit, c to continue without paging--
#17 0x000055ceb9363ce2 in BackendRun (port=0x55ceb99f1920, port=0x55ceb99f1920) at postmaster.c:4431
#18 BackendStartup (port=0x55ceb99f1920) at postmaster.c:4122
#19 ServerLoop () at postmaster.c:1704
#20 0x000055ceb9364c10 in PostmasterMain (argc=1, argv=0x55ceb99c7270) at postmaster.c:1377
#21 0x000055ceb90f3886 in main (argc=1, argv=0x55ceb99c7270) at main.c:228
Thank you
Marcel
Am 04.11.19 um 15:24 schrieb Tom Lane:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2019-Nov-04, Marcel Ruff wrote:
Now I have upgraded to postgresql 12 and get a crash about once per day,
...
How can I track down the problem?
The first you need to do is obtain a crash dump.  This page may help:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_reproducibly_crashing_backend
Also, as long as you're building from source anyway, you might pull down
v12 branch tip from our git repo, or use a nightly snapshot tarball [1]
to see if the problem's already fixed.
		regards, tom lane

[1] https://www.postgresql.org/ftp/snapshot/12/
--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com

--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com

Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

From

Tom Lane

Date:

10 November 2019, 18:59:16

Marcel Ruff <ruff@netwake.com> writes:
> I have compiled
>    git clone git://git.postgresql.org/git/postgresql.git
> to find out if this is more stable.
> But /pg_ctl start/ says:
>   /"The data directory was initialized by PostgreSQL version 12, which
> is not compatible with this version 13devel"/

You should do "git checkout REL_12_STABLE" and build from that branch.

(It's advisable to do "git clean -dfx" to make sure you don't have
any leftover build products from the master-branch build, first.
The build process isn't natively smart enough to deal with this
scenario reliably.)

            regards, tom lane

Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

From

Marcel Ruff

Date:

10 November 2019, 21:39:01

in current 12 branch I get

make[2]: Verzeichnis „/opt/postgresql/src/backend/parser“ wird betreten
'/usr/bin/perl' ./check_keywords.pl gram.y ../../../src/include/parser/kwlist.h
/usr/bin/bison -Wno-deprecated -d -o gram.c gram.y
/usr/bin/bison: invalid option -- 'W'
Usage: /usr/bin/bison [-dltvyVu] [-b file-prefix] [-p name-prefix]

Thank you
Marcel

Am 10.11.19 um 16:59 schrieb Tom Lane:

Marcel Ruff <ruff@netwake.com> writes:

I have compiled
   git clone git://git.postgresql.org/git/postgresql.git
to find out if this is more stable.
But /pg_ctl start/ says:
  /"The data directory was initialized by PostgreSQL version 12, which
is not compatible with this version 13devel"/

You should do "git checkout REL_12_STABLE" and build from that branch.

(It's advisable to do "git clean -dfx" to make sure you don't have
any leftover build products from the master-branch build, first.
The build process isn't natively smart enough to deal with this
scenario reliably.)
		regards, tom lane

--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com

Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

From

Tom Lane

Date:

10 November 2019, 23:23:00

Marcel Ruff <ruff@netwake.com> writes:
> in current 12 branch I get
> make[2]: Verzeichnis „/opt/postgresql/src/backend/parser“ wird betreten
> '/usr/bin/perl' ./check_keywords.pl gram.y
> ../../../src/include/parser/kwlist.h
> /usr/bin/bison -Wno-deprecated  -d -o gram.c gram.y
> /usr/bin/bison: invalid option -- 'W'
> Usage: /usr/bin/bison [-dltvyVu] [-b file-prefix] [-p name-prefix]

Hmph.  What version of bison are you using?
(exact output of "bison -V" please; also, where'd you get it from)

            regards, tom lane

Re: PostgreSQL 12 crash with segmentation violation in heap_freetuple

From

Marcel Ruff

Date:

03 December 2019, 13:12:36

FYI

with the self compiled release 12.1 the crash has disappeared,

thank you for your world leading DB

Marcel

06.11.19 um 07:48 Marcel Ruff:

Hi,
here is the crash dump, it is the current postgresql 12 release (not yet a current git clone) on Debian Linux with 40G RAM and AMD Opteron 23xx (Gen 3 Class Opteron)
    ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-pam --with-openssl --with-libxml –with-libxslt –with-llvm --enable-debug
    make -j 8
    make install
    cd contrib
    make -j 8
    make install
and the default postgresql.conf but with jit = false (it also happens with jit = on):
--------------
[New LWP 21468]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: watchee watchee 127.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at ../../../../src/include/utils/memutils.h:127
127             context = *(MemoryContext *) (((char *) pointer) - sizeof(void *));
(gdb) where
#0 0x000055ceb9518cc3 in GetMemoryChunkContext (pointer=0x0) at ../../../../src/include/utils/memutils.h:127
#1 pfree (pointer=0x0) at mcxt.c:1033
#2 0x000055ceb90fcfe5 in heap_freetuple (htup=<optimized out>) at heaptuple.c:1340
#3 0x000055ceb92931a1 in tts_buffer_heap_clear (slot=0x55ceba097a18) at execTuples.c:652
#4 0x000055ceb9293b05 in ExecClearTuple (slot=0x55ceba097a18) at ../../../src/include/executor/tuptable.h:428
#5 ExecForceStoreHeapTuple (tuple=0x55ceb9aad760, slot=0x55ceba097a18, shouldFree=<optimized out>) at execTuples.c:1446
#6 0x000055ceb926b851 in ExecBRUpdateTriggers (estate=estate@entry=0x55ceb9a4e090, epqstate=epqstate@entry=0x55ceb9a4ed28, relinfo=relinfo@entry=0x55ceb9a4e300,
    tupleid=tupleid@entry=0x7fff3cbcb92a, fdw_trigtuple=fdw_trigtuple@entry=0x0, newslot=newslot@entry=0x55ceba097a18) at trigger.c:3109
#7 0x000055ceb92ac464 in ExecUpdate (mtstate=mtstate@entry=0x55ceb9a4ec30, tupleid=0x7fff3cbcb92a, oldtuple=0x0, slot=0x55ceba097a18, planSlot=0x55ceba0978b8,
    epqstate=epqstate@entry=0x55ceb9a4ed28, estate=0x55ceb9a4e090, canSetTag=true) at nodeModifyTable.c:1072
#8 0x000055ceb92ad862 in ExecModifyTable (pstate=0x55ceb9a4ec30) at nodeModifyTable.c:2223
#9 0x000055ceb928860b in ExecProcNode (node=0x55ceb9a4ec30) at ../../../src/include/executor/executor.h:239
#10 ExecutePlan (execute_once=<optimized out>, dest=0x55ceb977fb60 <donothingDR>, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_UPDATE,
    use_parallel_mode=<optimized out>, planstate=0x55ceb9a4ec30, estate=0x55ceb9a4e090) at execMain.c:1646
#11 standard_ExecutorRun (queryDesc=0x55ceba065378, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:364
#12 0x000055ceb93d9140 in ProcessQuery (plan=<optimized out>,
    sourceText=0x55ceba065140 "update Location set enmea=$1, guid=$2, latDeci=$3, lonDeci=$4, modifiedByLoginName=$5, poiObjectId=$6, timestamp=$7, TRACK_ID=$8 where LOCATION_ID=$9", params=0x55ceba065268, queryEnv=0x0, dest=0x55ceb977fb60 <donothingDR>, completionTag=0x7fff3cbcbdd0 "") at pquery.c:161
#13 0x000055ceb93d9370 in PortalRunMulti (portal=portal@entry=0x55ceb9a31750, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false,
    dest=0x55ceb977fb60 <donothingDR>, dest@entry=0x55ceb99cd950, altdest=0x55ceb977fb60 <donothingDR>, altdest@entry=0x55ceb99cd950,
    completionTag=completionTag@entry=0x7fff3cbcbdd0 "") at pquery.c:1283
#14 0x000055ceb93d9e51 in PortalRun (portal=portal@entry=0x55ceb9a31750, count=count@entry=1, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=false,
    dest=dest@entry=0x55ceb99cd950, altdest=altdest@entry=0x55ceb99cd950, completionTag=0x7fff3cbcbdd0 "") at pquery.c:796
#15 0x000055ceb93d7557 in exec_execute_message (max_rows=1, portal_name=0x55ceb99cd540 "") at postgres.c:2090
#16 PostgresMain (argc=<optimized out>, argv=argv@entry=0x55ceb99f5958, dbname=<optimized out>, username=<optimized out>) at postgres.c:4297
--Type <RET> for more, q to quit, c to continue without paging--
#17 0x000055ceb9363ce2 in BackendRun (port=0x55ceb99f1920, port=0x55ceb99f1920) at postmaster.c:4431
#18 BackendStartup (port=0x55ceb99f1920) at postmaster.c:4122
#19 ServerLoop () at postmaster.c:1704
#20 0x000055ceb9364c10 in PostmasterMain (argc=1, argv=0x55ceb99c7270) at postmaster.c:1377
#21 0x000055ceb90f3886 in main (argc=1, argv=0x55ceb99c7270) at main.c:228
Thank you
Marcel
Am 04.11.19 um 15:24 schrieb Tom Lane:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
On 2019-Nov-04, Marcel Ruff wrote:
Now I have upgraded to postgresql 12 and get a crash about once per day,
...
How can I track down the problem?
The first you need to do is obtain a crash dump.  This page may help:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_reproducibly_crashing_backend
Also, as long as you're building from source anyway, you might pull down
v12 branch tip from our git repo, or use a nightly snapshot tarball [1]
to see if the problem's already fixed.
		regards, tom lane

[1] https://www.postgresql.org/ftp/snapshot/12/
--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com

--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com