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

From Tom Lane
Subject Re: standalone backend PANICs during recovery
Date
Msg-id 23650.1472561302@sss.pgh.pa.us
Whole thread Raw
In response to Re: standalone backend PANICs during recovery  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: standalone backend PANICs during recovery  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> On Wed, Aug 24, 2016 at 5:07 PM, Bernd Helmle <mailings@oopsware.de> 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 thinking about it, my opinion is still the same. Let's
> prevent a standalone backend to start if it sees recovery.conf.
> Attached is a patch and the CF entry is switched as ready for
> committer to move on.

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 readRecoveryCommandFile() error out?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: sequences and pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: sequences and pg_upgrade