Re: Stefan's bug (was: max_standby_delay considered harmful)

On Mon, May 17, 2010 at 7:44 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, May 17, 2010 at 8:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> (1)
>>> Smart or fast shutdown requested in PM_STARTUP state always removes
>>> the backup_label file if it exists. But it might be still required
>>> for subsequent recovery. I changed your patch so that additionally
>>> the postmaster skips deleting the backup_label in that case.
>>
>> Can you explain in a little more detail how this can cause a problem?
>> I'm not very familiar with how the backup label is used.
>>
>> Also, why is this different in PM_STARTUP than in PM_RECOVERY?
>> PM_RECOVERY doesn't guarantee that we've reached consistency.
>
> Before the startup process sends the PMSIGNAL_RECOVERY_STARTED signal
> (i.e., when the postmaster is in PM_STARTUP state), it reads the
> backup_label file to know the recovery starting WAL location, saves
> that information in pg_control file, and rename the file "backup_label"
> to "backup_label.old".
>
> If the backup_label file is removed before pg_control is updated,
> subsequent recovery cannot get the right recovery starting location.
> This is the problem that I'm concerned.
>
> The smart shutdown during recovery and the fast shutdown might call
> CancelBackup() and remove the backup_label file. So if shutdown is
> requested in PM_STARTUP state, the problem would happen.

OK, I think I understand now.  But, the SIGTERM sent by the postmaster
doesn't kill the recovery process unconditionally.  It will invoke
StartupProcShutdownHandler(), which will set set shutdown_requested =
true.  That gets checked by RestoreArchivedFile() and
HandleStartupProcInterrupts(), and I think that neither of those can
get invoked until after the control file has been updated.  Do you see
a way it can happen?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company