Re: [HACKERS] standalone backend PANICs during recovery

--On 3. September 2016 um 02:05:00 -0400 Tom Lane wrote: >> 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 > >>

Re: [HACKERS] standalone backend PANICs during recovery

Bernd Helmle writes: > 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]

Re: [HACKERS] standalone backend PANICs during recovery

Michael Paquier writes: > On Tue, Aug 30, 2016 at 11:00 PM, Tom Lane wrote: >> Thinking about it some more ... what we actually need to prevent, AFAICS, >> is standby_mode becoming true in a standalone backend. > I have spent some time playing with

Re: [HACKERS] standalone backend PANICs during recovery

On Tue, Aug 30, 2016 at 11:00 PM, Tom Lane wrote: > Michael Paquier writes: >> Does the attached suit better then? > > Thinking about it some more ... what we actually need to prevent, AFAICS, > is standby_mode becoming true in a standalone backend.

Re: [HACKERS] standalone backend PANICs during recovery

Michael Paquier writes: > Does the attached suit better then? Thinking about it some more ... what we actually need to prevent, AFAICS, is standby_mode becoming true in a standalone backend. If you don't set that, then the process will do PITR recovery, but I'm not

Re: [HACKERS] standalone backend PANICs during recovery

On Tue, Aug 30, 2016 at 10:24 PM, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Aug 30, 2016 at 9:48 PM, Tom Lane wrote: >>> Hm, StartupXLOG seems like a pretty random place to check that, especially >>> since doing it

Re: [HACKERS] standalone backend PANICs during recovery

Michael Paquier writes: > On Tue, Aug 30, 2016 at 9:48 PM, Tom Lane wrote: >> Hm, StartupXLOG seems like a pretty random place to check that, especially >> since doing it there requires an extra stat() call. Why didn't you just >> make

Re: [HACKERS] standalone backend PANICs during recovery

On Tue, Aug 30, 2016 at 9:48 PM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Aug 24, 2016 at 5:07 PM, Bernd Helmle wrote: >>> That said, i'm okay if --single is not intended to bring up a hot standby. >>> There are

Re: [HACKERS] standalone backend PANICs during recovery

Michael Paquier writes: > On Wed, Aug 24, 2016 at 5:07 PM, Bernd Helmle wrote: >> 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. > This patch is still on the CF app:

Re: [HACKERS] standalone backend PANICs during recovery

On Wed, Aug 24, 2016 at 5:07 PM, Bernd Helmle wrote: > 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. This patch is still on the CF app: https://commitfest.postgresql.org/10/610/ Even after

Re: [HACKERS] standalone backend PANICs during recovery

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

Re: [HACKERS] standalone backend PANICs during recovery

On Sun, Aug 21, 2016 at 1:41 AM, Tom Lane wrote: > So at this point I'm pretty baffled as to what the actual use-case is > here. It is easier to attach a debugger in this case to analyze the problem? > I am tempted to say that a standalone backend should refuse to > start at

Re: [HACKERS] standalone backend PANICs during recovery

I wrote: > In short, I don't think control should have been here at all. My proposal > for a fix is to force EnableHotStandby to remain false in a standalone > backend. I tried to reproduce Bernd's problem by starting a standalone backend in a data directory that was configured as a hot standby

Re: [HACKERS] standalone backend PANICs during recovery

[ got around to looking at this finally ] Alvaro Herrera writes: > Bernd Helmle wrote: >> While investigating a problem on a streaming hot standby instance at a >> customer site, i got the following when using a standalone backend: >> >> PANIC:

Re: [HACKERS] standalone backend PANICs during recovery

--On 5. April 2016 21:50:17 -0400 Robert Haas wrote: > If nobody's going to commit this right away, this should be added to > the next CommitFest so we don't forget it. Done. -- Thanks Bernd -- Sent via pgsql-hackers mailing list

Re: [HACKERS] standalone backend PANICs during recovery

On Sat, Apr 2, 2016 at 5:57 PM, Alvaro Herrera wrote: > Bernd Helmle wrote: >> While investigating a problem on a streaming hot standby instance at a >> customer site, i got the following when using a standalone backend: >> >> PANIC:

Re: [HACKERS] standalone backend PANICs during recovery

Bernd Helmle wrote: > While investigating a problem on a streaming hot standby instance at a > customer site, i got the following when using a standalone backend: > > PANIC: btree_xlog_delete_get_latestRemovedXid: cannot operate with > inconsistent data > CONTEXT: xlog redo delete: index

[HACKERS] standalone backend PANICs during recovery

While investigating a problem on a streaming hot standby instance at a customer site, i got the following when using a standalone backend: PANIC: btree_xlog_delete_get_latestRemovedXid: cannot operate with inconsistent data CONTEXT: xlog redo delete: index 1663/65588/65625; iblk 11, heap