Re: standalone backend PANICs during recovery

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: standalone backend PANICs during recovery
Date: 2016-08-24 08:07:44
Message-ID: 2DA7350F7296B2A142272901@eje.land.credativ.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

--On 20. August 2016 12:41:48 -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> So at this point I'm pretty baffled as to what the actual use-case is
> here. I am tempted to say that a standalone backend should refuse to
> start at all if a recovery.conf file is present. If we do want to
> allow the case, we need some careful thought about what it should do.

Well, the "use case" was a crashed hot standby at a customer site (it kept
PANICing after restarting), where i decided to have a look through the
recovery process with gdb. The exact PANIC was

2016-03-29 15:12:40 CEST [16097]: [26-1] user=,db=,xid=0,vxid=1/0 FATAL:
unexpected GIN leaf action: 0

I had the idea that it was quick and dirty to use a single backend. I was
surprised that this time it PANIC'ed differently....

That said, i'm okay if --single is not intended to bring up a hot standby.
There are many other ways to debug such problems.

--
Thanks

Bernd

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2016-08-24 08:07:54 Re: New SQL counter statistics view (pg_stat_sql)
Previous Message Michael Paquier 2016-08-24 07:33:11 Re: pg_dump with tables created in schemas created by extensions