Re: BUG #16094: Database entering recovery mode

This is all that I managed to retrieve using gdb

#0 0x00007f53d89eb7b7 in epoll_wait (epfd=3, events=0x55bc137a59c0,
maxevents=1, maxevents(at)entry=<error reading variable: Cannot access memory
at address 0x7ffee2d44afc>, timeout=-1, timeout(at)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

On Mon, Nov 4, 2019 at 5:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Bug reporting form <noreply(at)postgresql(dot)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
>