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

On Mon, May 17, 2010 at 8:02 PM, Robert Haas <robertmhaas(at)gmail(dot)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.

In the patch, if shutdown is requested in PM_STARTUP, the postmaster
skips calling CancelBackup() since the backup_label file might be
required.

>> (2)
>> pg_ctl -ms stop emits the following warning whenever there is the
>> backup_label file in $PGDATA.
>>
>>      WARNING: online backup mode is active
>>      Shutdown will not complete until pg_stop_backup() is called.
>>
>> This warning doesn't fit in with the shutdown during recovery case.
>> Since smart shutdown might be requested by other than pg_ctl, the
>> warning should be emitted in server side rather than client, I think.
>> How about moving the warning to the server side?
>
> Hmm, I'm not sure whether that's a good idea or not.  Perhaps we
> should discuss for 9.1?

Okay, this is not a critical problem.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center