Re: standalone backend PANICs during recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: standalone backend PANICs during recovery
Date: 2016-08-30 14:00:39
Message-ID: 28712.1472565639@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> 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 aware that there
is any problem with running that standalone, and maybe it's useful to
allow it for debugging purposes. So I'm thinking more like

/*
* Check for recovery control file, and if so set up state for offline
* recovery
*/
readRecoveryCommandFile();

+ /*
+ * We don't support standby_mode in standalone backends; that
+ * requires other processes such as WAL receivers to be alive.
+ */
+ if (StandbyModeRequested && !IsUnderPostmaster)
+ ereport(FATAL, ...);
+
/*
* Save archive_cleanup_command in shared memory so that other processes
* can see it.
*/

or we could put the check near the bottom of readRecoveryCommandFile.
Not sure which placement is clearer.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-08-30 14:12:23 some requests on auditing
Previous Message Tom Lane 2016-08-30 13:42:45 Re: Missing checks when malloc returns NULL...