Обсуждение: PostgreSQL 12 crash with segmentation violation
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
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
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
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/
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
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_backendAlso, 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
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
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 installand 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:228Thank you
MarcelAm 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_backendAlso, 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
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
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
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
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
FYI
with the self compiled release 12.1 the crash has disappeared,
thank you for your world leading DB
Marcel
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 installand 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:228Thank you
MarcelAm 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_backendAlso, 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