Re: BUG #16094: Database entering recovery mode

From: Mircea Pirv <mircea(at)reva(dot)tech>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16094: Database entering recovery mode
Date: 2019-11-07 08:07:42
Message-ID: CANpOcWCyB3F+n_9aKPXhydz=udnvk_FaFtOWeD8f=0JCV7h20A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi, Thanks for the reply. That's all the bt full command prints out when
the segmentation fault error occurs.

Thanks.
Mircea

On Thu, Nov 7, 2019 at 4:35 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Wed, Nov 06, 2019 at 03:37:31PM +0200, Mircea Pirv wrote:
> > #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
>
> Is this the only part of the stack you can get? WaitEventSetWait()
> gets called in three places, which are be-secure.c, syslogger.c and
> condition_variable.c. Could it be possible to see more of the actual
> callers here?
> --
> Michael
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tomas Vondra 2019-11-07 11:18:23 Re: Reorderbuffer crash during recovery
Previous Message Michael Paquier 2019-11-07 07:52:32 Re: The XLogFindNextRecord() routine find incorrect record start point after a long continuation record