This is all that I managed to retrieve using gdb
#0 0x00007f53d89eb7b7 in epoll_wait (epfd=3, events=0x55bc137a59c0, maxevents=1, maxevents@entry=<error reading variable: Cannot access memory at address 0x7ffee2d44afc>, timeout=-1, timeout@entry=<error reading variable: Cannot access memory at address 0x7ffee2d44ae8>) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
resultvar = 18446744073709551612
sc_ret = <optimized out>
#1 0x000055bc11790379 in WaitEventSetWaitBlock (nevents=<error reading variable: Cannot access memory at address 0x7ffee2d44afc>, occurred_events=<error reading variable: Cannot access memory at address 0x7ffee2d44ad8>, cur_timeout=<error reading variable: Cannot access memory at address 0x7ffee2d44ae8>, set=0x55bc137a5948) at ./build/../src/backend/storage/ipc/latch.c:1080
returned_events = 0
rc = <optimized out>
cur_event = <optimized out>
cur_epoll_event = <optimized out>
returned_events = <optimized out>
rc = <optimized out>
cur_event = <optimized out>
cur_epoll_event = <optimized out>
__func__ = <error reading variable __func__ (Cannot access memory at address 0x55bc11a5a510)>
__errno_location = <optimized out>
#2 WaitEventSetWait (set=0x55bc137a5948, timeout=<error reading variable: Cannot access memory at address 0x7ffee2d44ae0>, occurred_events=<error reading variable: Cannot access memory at address 0x7ffee2d44ad8>, nevents=<error reading variable: Cannot access memory at address 0x7ffee2d44afc>, wait_event_info=<optimized out>) at ./build/../src/backend/storage/ipc/latch.c:1032
rc = <optimized out>
returned_events = 0
start_time = <error reading variable start_time (Cannot access memory at address 0x7ffee2d44b00)>
cur_time = <error reading variable cur_time (Cannot access memory at address 0x7ffee2d44b10)>
cur_timeout = <error reading variable cur_timeout (Cannot access memory at address 0x7ffee2d44ae8)>
Backtrace stopped: Cannot access memory at address 0x7ffee2d44b78
PG Bug reporting form <noreply@postgresql.org> writes:
> We've updated our database from 10.6 to 12.0 recently and we keep
> encountering an error which says that the database is entering recovery
> mode.
> ...
> In the logs the only error we see, is a segmentation fault, when replication
> tries to run.
It should be possible to collect a stack trace for the segfault,
which would greatly assist debugging this. Please see
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane