Re: standalone backend PANICs during recovery - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: standalone backend PANICs during recovery
Date
Msg-id 2DA7350F7296B2A142272901@eje.land.credativ.lan
Whole thread Raw
In response to Re: standalone backend PANICs during recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: standalone backend PANICs during recovery  (Michael Paquier <michael.paquier@gmail.com>)
Re: standalone backend PANICs during recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

--On 20. August 2016 12:41:48 -0400 Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_dump with tables created in schemas created by extensions
Next
From: Haribabu Kommi
Date:
Subject: Re: New SQL counter statistics view (pg_stat_sql)